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!