One of the things that many agilists struggle with, particularly in the beginning, is what constitutes a “good” story. Many people start out with the familiar agile format of “as a user, I want to do this, for that reason,” but quickly find themselves running into issues of finding the right story size, complexity, scope, and various other factors. Fortunately, experience has provided a good framework for managing these issues.
Mike Cohn specifies six fundamental attributes of a good user story in his book User Stories Applied. These are (1) independent, (2) negotiable, (3) valuable to users or customers/purchasers, (4) estimatable, (5) small, and (6) testable.
For the sake of planning and prioritization, stories should not be dependent on one another. Therefore, individual stories should be as atomic as possible to allow maximum flexibility of scheduling and development. However, situations often arise where stories have inherent dependencies, such as payment processing, where the first story will incur the overhead of building the supporting infrastructure, which will then reduce the size/complexity of the remaining stories that take advantage of it. The problem, of course, being that this will force the team to attempt to attack the prioritization of dependent stories while the stories are still being defined, so that the individual stories could be properly estimated.
One solution to this is to roll all the dependent stories into a single story. This is applicable if the resulting story is still relatively small. However, if collapsing the stories results in something large and complex, another strategy is to temporarily treat the infrastructure development as a separate story for estimating purposes, and annotate, during story prioritization, that this story should be rolled into the first story that requires the infrastructure to be built. The resulting combined story should then be re-estimated, and overall priority adjusted accordingly.
The second attribute is that stories are negotiable. By definition, user stories are placeholders for discussion and progressive elaboration. Thus, stories should be defined, at any given time, only to the level needed to suit the purposes of estimating and prioritization with respect to the applicable planning horizon. For release planning, this is at the relatively high level needed to provide a “good enough” estimate as to size and complexity. Later, during iteration planning, more detail will be added, as needed, to provide a “good enough” estimate of tasks (and duration) needed to plan the iteration. And, during daily planning, even more detail may be added in the form of diagrams and other artifacts that a developer may need to actually develop it. However, at every step, the attribute of negotiability is maintained, as acquired domain knowledge, overall construction, and user feedback work to refine desired functionality. Note, also, that this may trigger splitting of a story and/or re-estimating.
The third attribute is value to users or customers/purchasers. In his definition of this attribute, Mike Cohn makes the distinction between those who use the software, and those who purchase the software. For example, users don’t generally care which platform a software package runs on, as long as it runs on theirs. However, a purchaser may have a requirement that the software support specific versions of Internet Explorer (or Firefox, etc.), or some other standardized platform. These would be captured as stories for estimation and prioritization, along with stories for specific functionality requested by the users.
What about developers, you may ask? Isn’t it possible that they have stories – often related to specific architectures and technical errata – that should be defined and placed on the backlog?
The answer to this is usually no. While these may be of benefit to the programmers, they don’t necessarily demonstrate measurable benefit to the users and/or purchasers of the product. Therefore, when these stories arise, they should be worded with respect to the value they provide to the users/purchasers, such as “business rules should be processed in ten seconds or less” as opposed to “the system should use an n-tier architecture to improve performance.” This allows the stories to be worded in a way such that they can be prioritized in relation to the other, user/purchaser stories on the backlog, and allows the developers to define solutions to specific problems, instead of general solutions that may be harder to quantify (and justify) with respect to business value.
The fourth attribute is that stories be estimatable. Obviously, this is an important attribute, since estimating story size is a central part of the planning and prioritization process. However, Mike Cohn points to three fundamental issues that may impede story estimation: Lack of domain knowledge, lack of technical knowledge, and story size.
If the development team is having a difficult time estimating a story because it doesn’t fully understand the feature, then this as a signal that the user(s) who asked for the story need to provide more information so the team can make an informed estimate. If the story can’t be estimated because of unfamiliar (or non-existent) technology, then the answer is to either acquire people who understand the technology, train team members on the technology, or conduct a small research project (or prototype) to gain enough understanding so as to provide a reasonable estimate. If a story is too large, then it should be split in accordance with the guidelines provided next.
The next attribute of a good story is size; specifically, smaller is generally better. This is not to say that a story can’t be too small, because it can. But, to a point, smaller is usually better because smaller stories tend to be easier to estimate, and with less variability than larger stories.
When it comes to story size, Mike Cohn identifies two basic determinates: compound stories, such as epics, that contain additional sub-stories, and complex stories that do not easily lend themselves to splitting into smaller stories. Splitting of compound stories is generally relatively easy: you just split the story into its constituent parts (minding dependencies, as previously noted). Complex stories, however, can be difficult to split because they may contain sub-stories that are tightly interrelated, or some other issue that makes splitting difficult.
One common way of splitting complex stories is called “slicing the cake.” By this method, the story is sliced by identifying the minimum amount of acceptable functionality that cuts across all layers of the underlying technology or process, then splitting everything else out into a separate story as “additional functionality.” This way, the users can be provided with something that works, albeit in a reduced configuration, with the option to add the rest of the functionality as priority determines. Another way of splitting complex stories is to create a separate story called a “proof of concept.” This is generally useful when working with new or little understood technology, and allows a prototype to be produced that provides an example of a working solution. Once the proof of concept has been completed, knowledge gained can be used to provide a better estimate for the original story.
The final attribute of a good story is that it is testable. Non-testable stories usually manifest themselves as vague requirements, such as “the user must have an enjoyable experience,” or something equally non-quantifiable. Stories such as this should be discarded, or rewritten in quantifiable terms. For example, “the user must have an enjoyable experience” can be rewritten as “the application must score at 80% or above on the provided user survey.” This provides a distinct, testable metric which allows the story to be quantified and prioritized.
So, there you have it! Six attributes that provide an excellent framework for identifying and wording user stories in such a way as to make them easier to estimate, plan, and achieve.