Much like modern smartphones, some user stories are just too big for their own good – and the good of your development team. In fact, many teams limit the maximum size for user stories pulled into a sprint. Anything too big gets broken down into smaller pieces or put on hold.
Scrum teams have a handful of effort point scales at their disposal [LINK], but they all have one thing in common: they work best when applied to the simplest story possible.
Consider your morning routine. If asked how complex it was to get ready for work, how would you assign effort? Thinking nebulously, you might look at it like this: make the bed, eat breakfast, shower, brush teeth, get dressed and get out the door. That might look like a 20-point adventure.
But what if that morning were broken down into multiple, discrete actions? Your morning might now look like:
Eat Breakfast…
- Take eggs, bacon and milk out of fridge
- Heat stovetop
- Cook eggs and bacon in skillet
- Start coffee
- …etc.
Get Dressed…
- Put on underwear.
- Put on socks.
- Put on pants.
- …etc.
These small, easily understood tasks don’t leave much to the imagination, and you can confidently assign 1 or 2 points to each. It’s almost a no-brainer to point as a team, and then complete as a developer.
Larger stories breed inaccurate effort pointing, which can cause serious problems during planning and throughout the sprint. Was that 20-point story really a 29? That 40 actually a 60? Unfortunately, your team probably won’t find out until the sprint is nearly finished.
In addition to size, as complexity grows, so does the inaccuracy of story estimates. Despite our best intentions, humans don’t always think linearly, so breaking stories down into simpler pieces can seriously increase developer certainty across the sprint backlog.
So, What’s a Scrum Master to Do?
First off, it’s important to remember that every team is different. Just like some mammoth-handed people will love a 7-inch phablet, some teams can handle big stories. However, most teams will find it easier to strike a balance between huge epics and small stories.
20s, 40s and 100s have their place – just not in your sprint. You’ll typically see those numbers when pointing the product backlog at the start of a new project, or when adding new items to the backlog throughout your development cycle. Assigning large effort to complex stories can be beneficial for product owners who need to prioritize epics based on value and effort. It may result in certain stories being pushed down the backlog, but the vagueness of the estimation can help the PO determine a story’s value.
As stories move up the backlog, however, it’s time to get serious about breaking them down, applying more refined acceptance criteria and more accurate estimates. After a few sprints together, your team should be able to determine a maximum story size, along with a warning threshold that triggers a team discussion. Bring in a larger story, but get ready to talk about how it can be refined.
Need a good tool to help your planning process? Planning Poker® is a proven way for teams to right-size their effort pointing, increasing collaboration and discussion during sprint planning. Take it for a spin today to see how it can benefit your next sprint.