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.  

User Stories: Make ‘em SMALLER, please!

User stories are the building blocks of whatever project we’re working on, are they not?  They give structure.  They give solidarity.  They stand things up.  Epics are the larger, overall stories that lay the foundation.  When building something, it is prudent to have the larger stories on the bottom and the smaller stories on the top.  I could get into the engineering aspects of building design, but I’m not smart enough to discuss such things.  I’ll stick to what I know.  Here’s what I’m getting at: make the user stories smaller than the epics.  This seems like a no-brainer, but too-big user stories are way too common.

One of the largest hurdles I face in early sprint planning sessions is user story size.  Yes, we’ve sized them previously in Release Planning, but once in a while we hit stories that are just BIG.  At first, new teams think they can tackle these monstrosities in one sprint, but then they quickly learn that just isn’t possible.  They over-commit and velocity takes a hit.  Have you been there?  I have.   

As the team grows together and matures, they realize what they can and can’t do.  They eventually get better at estimating.  In the meantime, how do we – the scrum masters – mitigate this? How do we get our teams from the Dark Side of too-big user stories to the Jedi Side of small, manageable stories? 

We guide them in breaking down these user stories into smaller stories, AND we give them the tools to do this. 

There are many resources at your fingertips.  I’ve perused these myself and have found that the INVEST model works best.  I got this from the guys over at Agile for All, but they got it from Bill Wake.  Check out his original article here.  In a nutshell, your stories should be the following:

·        Independent

o   Self-contained.  Not dependent on another user story.

·        Negotiable

o   Right up to committing to a user story in a sprint, you can rewrite it or change requirements.

·        Valuable

o   Self-explanatory.  The end-user needs to get something from it. 

·        Estimable

o   This means that “infinity” doesn’t work.  If the story is to be sized, it needs to be reasonable.

·        Small

o   You have to be able to complete it in one sprint.  This includes Dev AND QA work. 

·        Testable

o   QA folks need to know what the heck is expected as an outcome of this story.  It’s called user acceptance criteria. 

If your user stories fall short on one of these, then you need to rethink it.  Should it have more details?  Can tasks be divided out to create another user story that’s smaller?  Still stuck?  Check out Richard Lawrence’s workflow on how to split a user story.  I learned from him early in my agile career.  He knows what he’s talking about. 

Hopefully, once you’re done you can get the user stories into your sprint and be on your merry way.  Ideally, the product owner would have taken care of this breakdown and user story grooming outside sprint planning.  That’s not always the norm, and we scrum masters have to adapt!

What are some methods you incorporate into your planning to cut stories into bite-sized pieces?  Please chime in.  I’d love to learn from you!