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:
One starting point is the INVEST guideline for good stories. Let’s see how these stories hold up on the INVEST scale:
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:
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 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.