Backlog Grooming

I was going over some backlog grooming ideas with one of our Product Owners recently, so I thought I’d share these ideas with everyone.  

When preparing for sprint planning sessions, please take a moment to make sure the top 20 stories in your project backlog are “shovel ready”.  What do I mean by this?  Shovel Ready means that the stories have advanced to a state that allows teammates to IMMEDIATELY start working on them.  Ideally, this should be done even before Release Planning, but that can’t always happen.  

Here’s how we get them shovel ready:

·        UAC in EVERY user story

o   The team needs to know what the Product Owner’s definition of done is.  Your definition of done is your user acceptance criteria.  Don’t leave this to sprint planning.  We tend to go down rabbit holes as to what DONE actually means.  Product Owners, it is your job to set this standard, and it is the team’s job to tell you whether or not your UAC is possible in the context of the story.  THAT’S what needs to be discussed during planning. 

·        Possible story breakdown

o   Evaluate your user stories so succinctly that you can foresee whether or not they need to be broken down into smaller stories.  If you think you can group certain data flows or business rule variations, then do that ahead of time.  If you are not sure how to break them down, check out Richard Lawrence's How To Split a User Story again .  If you’re still at a loss, then by all means bring it to the team. 

·        Prioritize the backlog

o   Have the most important things you want worked on AT THE TOP of the backlog.  Make sure the team knows this priority, and make sure this priority is reflected in the goals you set for the sprint. 

·        Story Language

o   Please try to write stories in the format of “As a <blank> I want <blank> so that I can <blank>”.  This helps us keep the end user in mind.  I understand technical stories come up, but we need to try to stick to this idea as much as possible.

o   Be very specific in the language of the story.  Make it reflect the end goal.

If you have any other ideas you’d like to share, let’s share them!  Let me know if you have questions, as well.  Each of you have your own awesome style of handling user stories, so I encourage you to learn from one another as well.