This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask
I was pondering upon this problem for a while and understood that teams are missing a very important ceremony in the sprint called “Product Backlog Grooming” that would help in grooming, grouping, managing and organizing the user stories.
In short, the product backlog is the single source of requirements in agile, it is an ordered list of requirements, and the majority of the items in this list are the user stories. It needs to be continuously groomed whenever you see a need for it.
Here are few techniques for a team which can make their life easier when dealing with the user stories.
1. Groom the stories
Remove the stories from the backlog that are no longer needed.
Clarify the stories by elaboration the conditions of satisfaction as required.
Estimate the stories with the best known facts at that time.
Adjust the priority of the story with the permission of the Product Owner. The grooming activity is very much essential to maintaining the product backlog, otherwise it would become unmanageable.
2. Group the stories
We can group related together under one umbrella that helps us visualize the progress of stories. For example have all reporting templates related stories under ‘reporting’ group, all user management related stories under “user management” group and so on. This grouping of stories is called as “Themes” in agile.
Create high level groups when you start eliciting the requirements and try to group the stories accordingly as and when you add new stories to the backlog. Some tools like Rally, support a Parent-Child relationship and successor-processor relationship that supports user stories grouping.
3. Manage the Stories
Managing the stories is very simple. For each story in the backlog, the following attributes that would help in fetching the complete details of the origins of the story, that will make it very easy to track.
- User Story description
- Acceptance criteria
- Parent user story
- Priority
- Assumptions
- Dependencies
- Assigned to
- Estimate
- Team assigned to
- Group (if this story is grouped )
- Tasks associated
- Tests associated
- Status: Done, In-progress, completed, blocks etc… Impediments etc
Follow the DEEP model, as Mike Cohn calls it. DEEP stands for
Detailed
Appropriately Highest priority, more detail; lower priority, less, which are broken down into smaller stories for sprints/release.
Emergent
Growing and evolving overtime; Re-prioritized when items are added /deleted.
Estimated
The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points.
Prioritized
Items that are slated for the next couple of sprints
Organize the stories
Organizing the stories is easy, have team-specific backlogs. Have the stories that are related to your team only in your backlog. Themes are also used to organize stories for releases. Link your team stories on which you have dependency with other team, that way, you will come to know the status of other linked stories. Have frequent conversations with the Product Owner to prioritize and reprioritize stories. Help your Product Owner to remove the stories that aren’t belonging to your team.
Imagine your lawn in the back yard, how do you maintain it? It has to be maintained regularly? If not at some point of time it becomes unmanageable, grows haphazardly in all directions, making it difficult to maintain. Similarly, backlog grooming is not a onetime effort.
Do you think you need to consciously water your lawn, trim and manure it, so that it looks healthy? If you didn’t, imagine what might happen!
[activecampaign]