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!
