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? )
- 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.
So how do you make a story smaller? Here is a list of 13 patterns which I would recommend:
- Split on user roles/personae
- Split on conjunctions (and, or, etc).
- Split on functional components
- Split on test cases
- Split on business priorities
- Split on business process alternatives
- Sequences - Build the pipeline one segment at a time
- Sequences - Bore a pilot hole and then make the tunnel bigger
- Split on non-functional requirements
- Separate Goal and Function
- Split on Data Types
- Split on Data Operations
- Split on Levels of Quality
Here are some patterns which I would not recommend employing on the product backlog entries:
- Development Process
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.