Skip to main content

Getting to Good User Stories

User Stories have become so popular for identifying Product Backlog Items (PBIs) that the term 'Story' is often used as synonym for PBI — regardless of whether the item in question is formulated as a user story or not. Not all user stories are created equal - good user stories can be turned into functionality rapidly and predictably by a good Scrum team. Bad stories clog up the works and teams have troubles finishing them in the sprint. So what makes a good story and how do you get it small enough to implement in a sprint?

A user story answers three questions: Who? What? and Why? A user story leaves open the questions How? and When? Mike Cohn popularized the canonical form of a user story: As a <class of user> I want <some function> to achieve <some purpose>. For example:
  • As a Job Hunter, I want to find and apply for interesting jobs, so I can find a good job and earn a living.
  • As an Internet shopper, I want to select books from a catalog and order them. (Technically this is not a user story, because their is no explicitly specified goal. Do we need to specify a goal here? Or is it self-explanatory? )
One starting point is the INVEST guideline for good stories. Let's see how these stories hold up on the INVEST scale:
  • Independent - the stories can be submitted to the team in any order - OK
  • Negotiable - how the stories are to be implemented is subject to discussion - OK
  • Valuable - the feature provides value to the customer or user - OK
  • Estimable - the team can estimate the effort involved - hmm, our sample stories are a bit vague
  • Small - they are definitely not small - they might be OK for planning for two quarters from now, but no way can they be implemented in a sprint
  • Testable - yes and no. I would argue that yes, they are testable, but that there is so much room for interpretation, that it is impossible to say what tests are needed and which tests are not needed to confirm that these stories were implemented properly.
If you are in doubt as to whether your stories are good stories, ask yourself if the stories answer the three questions (Who-What-Why) and ask your team if the story satisfies the INVEST criteria.

So how do you make a story smaller? Here is a list of 13 patterns which I would recommend:
  1. Split on user roles/personae
  2. Split on conjunctions (and, or, etc).
  3. Split on functional components
  4. Split on test cases
  5. Split on business priorities
  6. Split on business process alternatives
  7. Sequences - Build the pipeline one segment at a time
  8. Sequences - Bore a pilot hole and then make the tunnel bigger
  9. Split on non-functional requirements
  10. Separate Goal and Function
  11. Split on Data Types
  12. Split on Data Operations
  13. Split on Levels of Quality
This is a long list, so I will work through the list and provide more details about what each of them mean in the coming entries.

Here are some patterns which I would not recommend employing on the product backlog entries:
  • Spiking
  • Layering
  • Development Process
Spiking is simply dividing the story into analysis and implementation, with a time box and a set of set of questions to answer about the story. It is a good engineering practice, but the analysis part delivers no value to the customer or user. So I would call it part of backlog grooming and insist that it fit into the 10% or so of the team capacity which it invests to getting the backlog item "Ready" to implement.

Layering can be formulated as 'user' story: "As a developer, I want a DB-Schema, so I can deliver value to the customer in a future sprint." Development Process is pretty much the same: "As a developer, I want a spec, so I can implement some value in a future sprint." Both of these stories fail the Valuable test. They are not valuable to the customer or user.

BTW - There are cases where the developer is a legitimate user, such as when the developer needs a certain functionality to identify and fix problems. But when the developer needs an artifact to deliver value in a future sprint, this is a warning sign that you are falling back into waterfall thinking.


Daniel Serodio said…
That's an interesting paradox. When you split a User Story, it may become testable and estimable, but OTOH it ceases to provide value to the user - so the PO can't prioritize them - and they're not independent anymore.
Peter said…
Hi Daniel,

It's not a paradox if you split user stories vertically: each story after splitting still has a user/customer level acceptance test associated with it.

The acceptance test demonstrates the "V" in invest. Obviously the value of a split story may be very small, but it's not zero.

If you split stories "horizontally", i.e. Specifcation, DB layer, XML-Layer, UI-Layer, then you are in the situation you describe. There is no acceptance test except for the final layer.

This brings to a two-tiered concept of done. Level 1: the acceptance test for this story passes; Level 2, the collection of stories is useful enough to the customer to justify releasing it.

Level 2 done may be big enough that it cannot be accomplished in one sprint. So the P-O decides if that level has been achieved at the end of each sprint.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…