Creating user stories feels like common practice and is often experienced as ‘just a tool to communicate requirements’, but they can have a serious impact on the delivery of a team.
I’ve watched different product owners in different projects pouring requirements into user stories. Combined with my preferences when working as a product owner, I came to these 3 common scenarios:
1. Big user stories
Ex. User stories describing entire screens, steps in a workflow or entire integration services, have a negative impact on the evolution of a sprint.
This is how a burndown on one of those projects looked like:
The burndown shows days of no progression followed by a huge drop. This is because big user stories take longer to develop, causing longer queues for validation by the business. If the user story takes 4 days to develop, your sprint is half way through before the first feedback is gathered.
Big user stories tend to cause a lot of bugs due to the higher chance on misinterpretation, which again causes delays.
2. Big and Small user stories.
Ex. User stories describing entire screens mixed with user stories that describe extra functionality, detail pages, …
This is how a burndown of such a sprint backlog looks like:
Progression is more stable but has some periods without progression. These are due to the larger user stories which cause delays in the feedback loops. I noticed that a big user story which sits in the bottom of the sprint backlog will almost never be completely done by the time of the sprint review.
3. Small user stories
In my first experience as a product owner, I found it hard to slice user stories into small, valuable, testable chunks. You tend to get lazy and say “Let’s just do this screen as one user story, I’ll make sure the team understands it”.
Forget it, when it’s big, it’s hard to come to an exact same understanding. There’s just too much chance for misunderstanding.
This is how a burndown of a sprint backlog with small user stories looks like:
Progression is stable, no big fluctuations, only minor that are most of the time caused by bugs or even still small misinterpretations. But thanks to the small sizes of the user stories, feedback is received early and corrections are small.
Here’s an example of how a team comes to these small user stories.
When the product owner explains a new webpage during planning, the team asks itself “How can we slice this up, so we get rid this big log and end up with a couple of small ones?”
They often split it up like this:
1. As a … I want to create a customer without validation. 3 story points
This user story includes placing the fields on the screen, being able to save the data, some basic screen layout.
2. As a … I want to automatically look up the city of a customer when entering its postal code. 2 story points
This user story is an enhancement of the basic data entry screen which we developed in user story 1. Nice thing about the split is that business can choose to lower priority if other things are more valuable.
3. As a … I want to view a list of customers. 1 story point
Because user story 1 only allowed us to create a new customer, we need to be able to look at all the existing customers in the system.
4. As a … I want to search in the list of customers on name and address. 2 story points
We have created a list of customers, but it would be nice if we could do a search. Again, this may be lower priority for the business
5. As a … I want to validate a customer. 2 story points
Now we add some business rules. Birthdate must be a valid date, at least age of 18, …
In total we now have 10 story points, perhaps more or less the same as when we would have estimated the one big user story.
Big difference is that each user story is clear in its intentions and purpose. Testing is not pushed to the end of the sprint, but can keep up the constant pace. Business can provide feedback after user story 1, which gives them the opportunity to correct early, or come to new insights.
Every user story that gets an estimate higher than 3 gets challenged. Can’t we chop it up somehow?
Lean has shown us that queuing leads to waste and best results are received with a steady flow, to which small user stories contribute.