It is important to constantly be refining your backlog. This is accomplished through time-boxed meetings where the team performs an activity called grooming.
Backlog Grooming
There is an art and a science to grooming the backlog. It's an art because you know a properly groomed story when you see it. It's a science because there is a methodical process to follow to help us achieve the grooming.
A groomed story leaves no question of what needs to be done to deliver the story, fix the bug, or complete the task. Through establishing a grooming culture, having periodic meetings, and having the product owner think through stories with acceptance criteria in mind, we can set ourselves up for success.
Culture: Always Be Grooming
Those 15 minutes before the next call or waiting on your buddies to finish so you can head to lunch, why not review some stories and see if you can add any clarity. It's important to have the mindset that you should always be grooming.
Often it just takes a few minutes to note down the details for how a story should be implemented. Even if it is wrong, it's better than being blank. We'll mark things as Ready for Dev in our team grooming meetings. Anything that is wrong will be corrected and will often serve as a prompt for getting to the right thing faster.
Weekly Meeting
The weekly grooming meeting is where we take a roughed out item and polish it into a gem. Depending on the size of the project you might have 2-3 of these meetings per week for the first several weeks of the project. Ideally these should not go on for more than 2 hours. Even better is to cap at an hour as attention spans rapidly diminish and if your team is slogging through it you won't be getting their best.
The goal of this meeting is to talk through as many items in the backlog as possible and convert them from Planning to Ready for Dev. This can only be done if the team is agreeable that the issue has enough information to know what needs to be done.
In order to not get bogged down on a single issue that requires too much discussion, a general rule can be followed that argues for creating a Spike to do the discovery needed for an issue if it's taking to much time (5 minutes cap, for example).
The results of any quick discussion is documented on the issue and it's moved to Ready for Dev or the issue is skipped over and a Spike is created. It may be tempting for a team member to announce they'll just figure out it and be ready for next meeting with the details, but that is work that would be done that isn't tracked and is technically a Spike that is breaking the current sprint.
If a story seem to be too big, perhaps it is describing two or three related features, go ahead and break them down as part of this grooming meeting.
Lastly, a good practice is having the Product Owner on these calls to help answer questions the development team will have about different stories and bugs. In addition, the ScrumMaster and/or development team should be in the habit of eliciting acceptance criteria from the Product Owner for the stories before marking them as Ready for Dev.
Acceptance Criteria
A key grooming process component is capturing the criteria needed for the Product Owner to accept the story after development has completed.
The criteria that the team elicits from the Product Owner are the attributes, conditions, expectations that the Product Owner has that may or may not be explicit in his or her mind but will be used in evaluating the completeness of the feature before the work is accepted.
It is far better, to suss out this criteria by getting the Product Owner to think through "What will I need to see to be able to accept this story once development is complete?" and itemize them as part of the story description. You never can go wrong by having well defined acceptance criteria and it will often cut down on back and forth after a developer pushes their work for review by the product owner.
Example for the story As a user, I want to reset my password.:
- the email the user receives should have the content attached (see attachment)
- user should be redirected to login after new password is set
- the link in the password reset email should expire after 3 days]
Read more detail on the acceptance criteria concept in our blog post How We Use Trello: Acceptance Criteria.
Conclusion
The polishing and refinement of backlog items not only makes development more efficient but it develops a certain level of osmosis between the Product Owner and the development team.
For the development team, they will begin being able to have a sense of what the Product Owner wants that isn't explicitly stated. For the Product Owner, he or she will gain a very healthy appreciation for the complexities involved in building software. When the team is functioning as a unit like this they will achieve greater efficiencies in working together.
Next week, we will dive into another type of meeting that can only occur once backlog items are groomed and that is the pointing meeting. This is where we play some games, assign points, and make ready story items for development.