Monday, September 19, 2011

Gather Requirements the Agile Way

In the post Self-organize using Scrum we saw that Scrum supposes that the Product Owner can fill the Product Backlog with stories, ordered by the desired sequence of implementation. Furthermore Scrum supposes that the team estimates these stories and comes up with a Definition of Done that will ensure a common understanding of the desired quality constraints. It doesn’t say where the information comes from that is needed to do these things. Speaking with Jeff Sutherland (one of the founders of Scrum) – “this stuff magically appears”. In this section we will look at the way Agile requirements practices can help in this regard.

Agile requirements focus on what the user can do with the system rather than on what the system can do. Traditionally developers tend to decompose a system to be built into functions of the system. They are faced with the problem of building a complex system. To solve this problem they divide it into smaller problems until they reach a granularity of problems that are solvable. Although this is helpful for the developers, it doesn’t help users much in getting a clear view on their needs and what a solution could look like that that meets these needs. When users are confronted with a collection of functions in a traditional functional design, it is hard for them to imagine how they could use these functions to help them do their daily jobs. This diminishes their readiness to be involved.

Within iterative and Agile software development there are two approaches for capturing and detailing requirements: user stories and use case modeling. Use cases and user stories are a proven way to focus on what the user really wants to do with the system. They describe an interaction between a user and the system that delivers apparent value to the user or the organization. In this section we show how these approaches can come together.

The user story approach has a low level of ceremony and uses stories about what the user would like to do with the system. The short description of a user story usually has a form as shown in Figure 22.

Figure 22: Form  of User Stories
The persona form (the third form shown in Figure 22) is great in situations where people with different backgrounds can expect very different solutions. Imagine this story: “Grandma Theresa – with no computer experience whatsoever – wants to make cheap video calls to her grandson at the other side of the globe so that it is easier to keep in contact”. The resulting solution will be a great contrast to the one resulting from this one “Paul – who is a computer nerd – wants to make cheap video calls to his grandma at the other side of the globe so that it is easier to keep in contact”.

Short descriptions of user stories in the forms shown in Figure 22 are commonly used in a Scrum Product Backlog.

The fact that you're using user stories doesn't say much however about the form in which requirements are detailed. A user sitting next to a developer, discussing the solution, might be enough. A more elaborate story about how the user would like to use the system to reach his goal could be appropriate. It could also be necessary to write a whole lot of detailed test cases (the XP Test Driven Development practice) to figure out exactly how the system should behave or to make a detailed design so the developers have an idea of how the solution can be realized.

Use case modeling is a structured approach to capture and detail requirements and is shown in Figure 23. First the Vision is captured, describing a desired future state, the problem to be solved, stakeholders that are involved, what stakes they hold toward the solution and a high-level description of the qualities an appropriate solution should have.

Figure 23: Use Case Modeling Work Products
In the Use Case Model the scope of the system is explored and structured. It captures short Use Case descriptions (describing uses the users want to make of the system) at a level of detail, comparable to user stories. For that the forms expressed in Figure 22 can be used. The Use Case Model evolves just after or alongside the Vision, very early on in a development effort.

More detailed descriptions of the way users want to use the system are captured just in time for development in the form of Use Cases. A Use Case brings together all scenarios (describing a particular way in which the user uses the system) that lead to the same user goal. To create scenarios of comparable granularity it is a common practice to constrain scenarios to actions that are executed in one time, at one place, by one person. The Navigation Map is an aid to discuss and decide on a consistent navigation and look and feel throughout the solution.

When used in a Scrum context these work products form input for the Product Backlog level and Sprint Backlog level of planning as shown in Figure 24.

Figure 24: Use Case Modeling  as Input for Planning
Although use case modeling work products focus mainly on functional requirements, they also form a starting point for identifying acceptance criteria, structuring the solution and keeping the focus on a usable product. This is shown in Figure 25.

Figure 25: Use Case Modeling as Input for Architecture and Quality
A Product Acceptance Plan combines product-wide acceptance criteria with the strategy the business uses to organize acceptance. In an Agile context this strategy is mainly made up of iterative activities and helps team and business to level expectations on involvement and results. As such it provides constraints for the solution’s architecture and clues for a team’s Definition of Done.

In the post Maintain Stability using XP we saw that XP has a group of practices for Shared Understanding of the Code. It does not say however how this shared understanding is reached, other than working closely together on the code. To reach a shared understanding it also helps to elevate the level of abstraction and use models (or metaphors) to grasp the inherent complexity of code. They enable discussion of its structure and possible improvements to be made. A Software Architecture Document helps in communicating shared coding standards, design ideas and the high level structure of the solution.

Though all the work products we spoke about in this section can be helpful they are not a purpose on their own. They are merely aids to the real purpose: delivering value to the customer.

Other Relevant Posts: 
The Agile Spirit
Self-organize using Scrum

Maintain Stability using XP
Get Ready to Poker

External links:
Improving User Stories with Use Cases


  1. Certifications will definitely increase the salary significantly. For project management professionals, I would suggest them to attend any genuine agile scrum certification courses (eg. Scrum Master Certification). If not anything, at least it will give a boost to your career and salary.

    1. But most of all, start doing Agile, inspect and adapt and keep it simple stupid! :-)