How To Know Your Stories Are At The Right Level Of Detail

How to know when a story is at the right level of detail Stories are vital to the Product Backlog, Release Planning and Sprint Planning and delivering something of commercial or operational value iteratively and incrementally. The more experience you have with writing stories, and estimating story size using a relative unit of measure, the easier it will become for you to recognize when a story is at the right level of detail. When you are sizing your stories, at the Product Backlog level, a story should contain just enough detail for the team to be able to estimate its relative size to other stories. When estimating your stories, at the Sprint Backlog level, a story should contain enough detail for the team to be able to determine what the solution involves or what it will take them to deliver the story. Characteristics of good stories Stories are not written contracts or detailed requirements that the system-software must implement. Stories are short descriptions of functionality, the details of which are to be refined in a conversation between the Product Owner (aka, the business or customer) and the development team. The challenge comes in learning to include just enough detail. At the time the story is written some important details may become known, they should be included as acceptance criteria for the story, as shown in Figure 1.0. Figure 1.0 – A story and related acceptance criteria Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 1 of 5

When you’re discussing a story, and the story seems to be getting larger and larger (”what about x?”; “have you considered y?”), stop and ask, “What’s the simplest version of this?” Capture that simple version as its own story. You’ll probably have to define some acceptance criteria on the spot to keep it simple. Then, break out all the variations and complexities into their own stories. So, for example, this story: As a user I can search for flights between two destinations We can disaggregate1 this story into simple stories by splitting off variations like: As a user I can search for flights between two destinations specifying a max number of stops As a user I can search for flights between two destinations including nearby airports As a user I can search for flights between two destinations using flexible dates etc. The fact of the matter is some stories can be too big, some can be too small, and some can be just right. Story size does matter because if stories are too large or too small you cannot use them effectively in planning. Stories that are too big are called Epics. Epics are difficult to work with because they frequently contain multiple stories. For example, in a travel reservation system, “A user can plan a vacation” is an epic. Planning a vacation is important functionality for a travel reservation system but there is just too much functionality in this story; which will result in increasing the teams effort spent estimating the story size and degrade the accuracy of the story estimate. An epic should be split into smaller stories. Epics typically fall into one of two categories: • The compound story • The complex story A compound story is an epic that comprises multiple stories. For example, a job posting application may include the story “A user can post her resume.” When the team talks more about this story with the Product Owner, they find out the “post her resume” actually means: • that a resume can include education, prior jobs, salary history, publications, presentations, community service, and an objective • that users can mark resumes as inactive • that users can have multiple resumes • that users can edit resumes • that users can delete resumes 1 Disaggregation refers to splitting a story into smaller, easier-to-estimate pieces; page 55, Agile Estimating and Planning, by Mike Cohn Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 2 of 5

However, disaggregating an epic this way may go too far in the opposite direction, turning it into a series of stories that are too small. For example: • A Job Seeker can enter a date for each community service entry on a resume • A Job Seeker can edit the date for each community service entry on a resume • A Job Seeker can enter a date range for each prior job on a resume • A Job Seeker can edit the date range for each prior job on a resume Generally, a better solution is to group the smaller stories as follows: • A user can create resumes, which include education, prior jobs, salary history, publications, presentations, community service, and an objective • A user can edit a resume • A user can delete a resume • A user can have multiple resumes • A user can activate and inactivate resumes There are normally many ways to disaggregate a compound story. The preceding disaggregation is along the lines of create, edit, and delete, which is commonly used. This works well if the create story is small enough that it can be left as one story. An alternative is to disaggregate along the boundaries of the data. To do this, think of each component of a resume as being added and edited individually. This leads to a completely different disaggregation: • A user can add and edit education information • A user can add and edit job history information • A user can add and edit salary history information • A user can add and edit publications • A user can add and edit presentations • A user can add and edit community service • A user can add and edit an objective Unlike the compound story, the complex story is a story that is inherently large and cannot easily be disaggregated into a set of constituent stories. If a story is complex because of uncertainty associated with it, you should estimate the size of the story at the highest range of your estimating scale (1, 2, 3, 5, 8, 13, 21, 34, 55, 89). Then in your sprint have an investigate story to more clearly understand what the solution involves to deliver this story. For example, suppose the team is given the story “A company can pay for a job posting with a credit card” but none of the developers has ever done credit card processing before. The team would then decide to disaggregate the story in the sprint like this: Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 3 of 5

• Investigate credit card processing over the web • A user can pay with a credit card In this case the first story will send one or more developers on a spike. When complex stories are split in this way, always define a time-box around the investigative story, or spike2. Complex stories are also common when developing new or extending known algorithms. For example, a biotech company had a story to add novel extensions to a standard statistical approach called expectation maximization. The complex story, as part of sprint planning, was divided into stories: the first to research and determine the feasibility of extending expectation maximization; the second to add that functionality to the product. In situations like this one it is difficult to estimate the size of the story, so once again size the story at the highest range of your estimating scale (1, 2, 3, 5, 8, 13, 21, 34, 55, 89). Stories must also be written so as to be testable. Successfully passing its tests proves that a story has been successfully developed. If the story cannot be tested, how can the developers know when they have finished coding? Un-testable stories commonly show up for nonfunctional requirements, which are requirements about the software but not directly about its functionality. For example, consider these nonfunctional requirements: • A user must find the software easy to use • A user must never have to wait long for any screen to appear The preceding are not stories, they are details of a story to be captured as acceptance criteria associated with a story or stories. Sidebar Acceptance criterion such as “a user never has to wait long for any screen to appear” is not testable, because it says “never” and because it does not define what “wait long” means. Demonstrating that something never happens is impossible. A far easier, and more reasonable target, is to demonstrate that something rarely happens. This acceptance criterion could have instead been written as “New screens appear within two seconds in 95% of all cases”; an added bonus is an automated test can be written to verify this. Summary 1. Ideally, stories are independent from one another. This isn’t always possible but to the extent it is, stories should be written so that they can be developed in any order. 2. The details of a story are negotiated between the Product Owner and the team. 2 A spike is an experiment that allows developers to learn just enough about something unknown in a story, e.g. a new technology, to be able to estimate that story. A spike must be time-boxed. This defines the maximum time that will be spent learning and fixes the estimate for the spike. Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 4 of 5

3. Stories should be written so that their value to the Product Owner is clear. The best way to achieve this is to have the Product Owner write the stories. 4. Stories may be annotated with details, but too much detail obscures the meaning of the story and can give the impression that no conversation is necessary between the team and the Product Owner. One of the best ways to annotate a story is to write acceptance criteria for the story. 5. When stories are too big, compound and complex stories may be disaggregated into multiple smaller stories. 6. When stories are too small, multiple tiny stories may be combined into one bigger story. 7. Stories need to be testable. Tips - experiences from using this approach The more experience you have with writing stories, and estimating story size using a relative unit of measure (1, 2, 3, 5, 8, 13, 21, 34, 55, 89), the easier it will become for you to recognize when a story is at the right level of detail. When you are sizing your stories, at the Product Backlog level, a story should contain just enough detail for the team to be able to estimate its relative size to other stories. When estimating your stories, at the Sprint Backlog level, a story should contain enough detail for the team to be able to determine what the solution involves or what it will take them to deliver the story. Epics are okay to have on your Product Backlog as long as they are stories at the bottom of your Product Backlog (lowest in priority). When you are within 3 Sprints of these stories it is time to disaggregate them. It is okay and expected, for novices during their first couple of Sprints, to discover your estimates were either really low or really high. Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 5 of 5

How To Know Your Stories Are At The Right Level Of Detail

by rpannone on Mar 20, 2010

Accessibility

Categories

Upload Details

Usage Rights

Statistics

How To Know Your Stories Are At The Right Level Of Detail — Document Transcript