Id I S%
pdfcoffee.com-systems… q
)
Figure 5-12 Project characteristics radar chart for a project needing high BDUF
We explore each of these factors in turn:
. • Number of features: This indicates how many features (user stories) we need to deliver in our project. The need to create a large number of features typically points to increased efforts and a larger budget. We can see that a project with only a few features
might be able to be handled informally—we can list those user stories and maintain some of their details in our minds or in rough notes or with whiteboard jottings. However, as we begin to include an expanded number of features, it becomes harder and harder to keep track of all the stories, much less their details. Thus a larger number of stories pushes us toward BRUF (and therefore hybrid).
Number of features
The number of different software features that need to be delivered in a project. Often expressed as the number of user stories.
• Complexity of features: Closely related to the number of features is the complexity of the features we need to create. As with the number of features, highly complex features also point to increased efforts and budget needs. Complexity can arise in a number of ways: O ^ Intrinsic complexity: First, we may find individual features that are each complicated on their own—they may involve complex data, calculations, data visualizations, or other challenges. For example, in Chapter 4, the retail “search for products by photo” story would likely be a high-complexity feature. o ^ Requirements variations: Requirements may vary across different users, departments, or offices. For example, you may automate a calculation for users in the headquarters office, only to realize later that users in other offices perform the calculation differently. This can be resolved by getting all users to agree to perform the calculation in the same way. Alternatively, it may be necessary to support the calculation variations. Either way, this increases the need to create BRUF to document and communicate the variations among the various users. o ^ Coordinating with other projects and systems: Working on a system that needs to interact with other systems is more complex than working on a system that operates in isolation. To the extent this is so, we cannot expect other project teams to understand and communicate with us in an informal, agile manner. Instead, we typically need to create more formal documentation in order to communicate with those other projects and teams. Note that agile sometimes refers to this need to coordinate among other (agile) teams as coordinating an agile release train. Here, each agile team is a “car” in a “train” delivering changes in a coordinated manner. Coordinating meetings between these interacting teams is sometimes called a “Scrum of Scrums.” Agile authors often admit that these activities require a departure from a “pure” agile approach.
Complexity
The degree to which software features involve complex data and calculations, involve variations between business customers, or must be coordinated with other systems or subsystems.
Release train