A story about User Stories; Who writes them and how do you control the scope?

• What are they and why do you need them?
• Who writes them and how do you control scope?
• Where do you start and what about the planning?

You can also download all parts as one comprehensive PDF for easy printing or e-reading.

So who writes them?

That depends. In Scrum it is the product owner (the term I use in the rest of this article) who represents the customer(s), and he or she has full responsibility over the list of user stories that comprise the product or system (the product backlog). And since he is one most knowledgeable about the particular domain, usually he is also the one who is supposed to write the user stories. In reality however, it is a combined effort with the team that realizes the functionality. Writing good user stories is not trivial, you know.

Ideally, user stories comply to a number of requirements captured in the acronym INVEST. First, they should be as independent as possible. After all, the more independent they are from each other, the easier it is to change the priorities between stories. No doubt this might be difficult to achieve sometimes, but quite often you can fix that by splitting a big story or combining two small stories.

The second requirement is that a story should be negotiable, which means that the description of a story should promote a discussion later on in the project. As I wrote earlier, stories are no substitute for the functional design, but rather a reminder to discuss the details with the product owner just-in-time. If you write stories that provide too much detail upfront, then you might give the impression that no discussion is needed anymore and that would go against the entire essence of user stories.

The third requirement, value, demands that a user story must have business value. Take for instance the product catalog application I’ve mentioned before. A screen for adding products has no business value on its own. After all, as long as a potential customer cannot see those products yet, such a screen would not make a difference. Building both screens fully with all its bells-and-whistles is not an option either. But the product owner might just accept a first version that limits the customer functionality to a list of products with a description and a price. The ability to attach a product image could be built in the next version and is a separate user story. Unfortunately, breaking down functionality like that is not trivial, so it is important to work with the product owner to see which story has sufficient business value.

The fourth requirement states that every story must be estimable. This may sound silly, but once you find it difficult to estimate the size of a user story, it is very likely that the scope of that story is too wide. However, it’s normal that the estimates for stories that will be picked up at a later stage of the project are very rough. In fact, any attempt to provide a more detailed estimate may create the illusion that the key decisions were already made at the time of creation. As mentioned earlier in this article, it is important to estimate at the last responsible moment when you have the most up to date information available.

An obvious solution for ensuring that user stories are estimable is by keeping them small. A good sanity check that I've read somewhere in a blog is to ask someone in the team for an estimate for a fairly big story. If he or she answers that question with something along the line like: "Uhm, something like a month or so" then you can bet that the developer has no idea about the content and scope of the story. In that case it is not unwise to try to split this story into several smaller stories that still have business value but which scope is very limited.

And that brings us to the last letter of the acronym - the 't' for testable - not to be confused with automated testing or something like that. Instead, it refers to the fact that a user story must include acceptance criteria that should allow verification that the team’s interpretation of the story matches the original intention of the product owner. As the product owner has not seen the end-result yet, getting those criteria might get challenging sometimes. What could be helpful is to ask him how he would demonstrate that feature other users. In typical Scrum methodology for that is the how-to demo part of a story.

How do you limit the scope?

From my own experiences I know that finding the right scope is very difficult, especially in the presence of the product owner or another stakeholder. Something I found very helpful is by using so-called storyotypes. The idea is that a properly scoped story matches exactly one storyotype. If you fail to find a suitable storyotype than you can assume that the story is either too big, or too small, and you should combine or split them.

The concept of using stereotypes to scope user stories was first described by Gerard Meszaro in Using Storyotypes to Split Bloated XP Stories. In that article he identified the four storyotypes listed in the table below.

Now imagine a screen where you can search for products from a catalog. In an approach based on fish level use cases, the entire screen, including all business rules, available search fields and the entire look and feel of the product list, is treated as a single use case. But if you want to break down this particular screen into a smaller number of user stories that still comply with INVEST, those four storyotypes can be very helpful.

As a first story you could limit the searching functionality to only the name of a product and present the search results in the simple layout. That still provides enough business value and hence complies with the New Functionality storyotype. You can add any additional search options later as one or more Variations, and pimp up the look and feel using an UI Enhancement storyotype. If you have to give up some of those extra features due to lack of time, then your basic functionality is still valuable enough.

If you’ve already looked at the User Story work item in Visual Studio 2010 you might have noticed that it doesn’t have a storyotype field. But don’t worry. Adjusting the MSF Agile 5.0 process template is fairly easy to do, especially with the Team Foundation Server 2010 Power Tools. However, for your convenience, you can download a customized version of the User Story work item type from my blog.

What’s it worth?

In reality, those storyotypes have really helped me to get the scope right in discussions with the product owner. Yet, I still noticed several types of activities that do not quite suite any of the four storyotypes nor any of the requirements defined by INVEST. I regularly run into requirements that do not originate from the product owner, but which are still important for getting and keeping the system into production. For instance, the IT department may have specific demands in order for the system to be deployed in their infrastructure. Or maybe they require real-time logging so that they can monitor the system. As an architect you probably want the system to be built in a certain way so that the maintainability is guaranteed. And as a team leader you may want to set-up an automatic nightly build to track the quality of the development activities.

You could embed these tasks within one of the normal user stories. But you could also reserve a fixed percentage of your capacity for those. However, I believe that it is better to keep all of those non-functional issues explicitly visible in your project. It also helps in the discussion with the product owner when you have to explain why you will take up only a limited number of user stories in a particular sprint. For these reasons, my user stories must have project value and not necessarily business value.

Next time, I’m going to talk a bit more about the planning aspects of a user story, and introduce even more storyotypes.