As a product manager, a large part of my time is spent writing and enhancing user stories. Often, I worry if I’ve got enough information in my stories. Then, later I wonder how much time I’ve wasted by adding unnecessary details.
Below are my thoughts on how I can tell if a story is complete. Some PMs follow the INVEST mnemonic to remind them of the characteristics of a good user story. The “S” emphasizes how the right size story benefits both PMs and developers. Each time I work with a new team, I adjust it to meet their needs, but this is my basic checklist on whether I’ve got the right size story.
- Does my story have a beginning and an end?
- Do my acceptance criteria match the goals?
- Should my story be divided into smaller full stories?
If the answers the the first two questions are Yes and the last one is No, I know my story is in good shape. Developers may still ask for more detail or to split the story, but it’ll happen less often.
1. Does my story have a beginning and an end?
This may seem obvious, but recently a Pivot asked me where one of my stories ended. He was totally right! Basically like any other story, there’s a start and a finishing point, in this case for the user.
A story must take the user someplace, generally their goal. The goal is often put as “So that…” and is crucial for communicating the business value of the story to the team.
An example of a good story with clear goal:
Title:
A user should be able to Print the summary report
Description:
As a user who is looking at the summary report
I want to be able to print the summary report
So that I can have a hard copy of it
Acceptance Criteria:
Given that I’m a user looking at a summary report
When I click the “Print” button
Then the summary report should be printed
This story works because we know that the user starts with on the summary report screen and ends up with a printed copy of the report. The developers will be able to scope the complexity of this and understand what results functional code will produce.
2. Do my acceptance criteria match the goals?
Looking at the example above the acceptance criteria clearly match up with the goal stated in the “So that” part of the description, but other stories are more complicated. What if the stated business value is accuracy of data, or manager oversight, or enhanced knowledge of a location? (all real example from stories in current Pivotal Labs projects) That’s when acceptance criteria is even more important.
Acceptance criteria is where the developers will look to set up tests. They are also what a product owner’s ability to reject a story is based on. There should be a clear definition of what’s required for the story to be considered finished. ALL expected behaviors should be listed. The title and description are more of points for discussion, the acceptance criteria is the part with direct instructions.
Look at what updates are necessary to the acceptance criteria when a small change is made to the story above:
Title:
A user should be able to Print the summary report
Description:
As a user
I want to be able to print the summary report
So that I can have a hard copy of it for my daily records
Acceptance Criteria:
Given that I’m a user looking at a summary report
When I click the “Print” button
Then the summary report should be printed
And today’s date stamp should be visible on the print out
These first two tests are both strongly correlated with ensuring that the story has business value. The final item on the checklist is more about getting accurate estimations on what will be involved in getting the story completed.
3. Should my story be divided into smaller full stories?
This may also be paraphrased as “does the story cover too much?” We all know that if a story is scoped at the highest point value it should probably be divided, but can a PM predict that a story is too big without the developers scoping and preemptively divide it to save time?
Positive benefits to smaller stories are improved accuracy in pointing by developers, the ability to prioritize the parts separately based on business value, and the opportunity to have more robust acceptance criteria for each story. Per my second point, detailed acceptance criteria are key to a good story, so having enough space to focus on what’s required will be helpful.
Some product folks believe the story should include the smallest piece of functionality that can be described. This is excellent advice for new product managers, those who are less experienced with agile, and when working with a new team. The more comfortable I get with my development team, the more this becomes a sliding scale, but I still think about it every time I save a story.
Here is an example of a BAD story which is way too complex and should be separated:
Title:
User should be able to print and save the summary report from dashboard and summary report screen
Description:
As an user
I want to to print and save the summary report from dashboard and summary report screen
So that I can have a hard and soft copy of it for my daily records
Acceptance Criteria:
Given that I’m an admin who is on my dashboard or summary report screen
When I click “Print” or “Save”
Then the report should be printed or saved
And my manager should be notified that it was printed or saved
This story involves both Print and Save functionality, then it describes user interactions on multiple screens, and finally it includes an additional notification to a different user. What developer wouldn’t classify this story as overly complex?
It’ll be much easier for them to evaluate the story if it’s divided into a few smaller ones with clear goals and associated acceptance criteria for each action, screen, or user. This blog post is already a little too long and there’s a few options on how to divide this monster story into smaller ones, so I’m going to leave that to your imagination.
You may be wondering about the medium and small sized stories, and whether should they be combined into larger ones. Chances are if the story can meet the criteria listed in #1 and #2 there’s no need to combine them. You know, unless a developer suggests it…
Stay tuned for how to prioritize your stories now that they are ready for scoping.
