Have you ever actually bitten off more than you can chew? It’s not a pleasant feeling. And neither is an overloaded backlog. Like a juicy steak, a healthy sprint backlog is best when it’s consumed in bite-sized portions, or user stories. (And, if you’ve got a gaggle of oversized stories, your best course of action is good red wine.)
Not only do smaller user stories make it easier to digest (ahem) a sprint, but the conversations that are produced while breaking them down facilitate a deeper understanding of the work. When you’re faced with the old ’96er, here are some tips to help you clean your plate.
Find your limits.
Take a look at your team’s historical performance on differently sized stories. You should see a break point at which stories get unwieldy or balloon unexpectedly. When stories cause sprint bloat, it’s likely a symptom of unaccounted-for complexity. If those 13-point stories always end up dragging through multiple sprints, it’s time to agree that your stories need to be sized at an 8 or below. Limiting story size gives your team a signpost for when they need to dig deeper into a story before it’s sprint-ready.
Get epic.
Sometimes it seems like a huge story will only add business value when it’s fully implemented. When faced with this type of feature, teams, like many an aging rapper, struggle to break it down. To help them gain perspective, consider positioning huge stories as epics, and track the features’ business value to the epic instead. So a set of smaller stories would incrementally fulfill the epic, allowing continued progress on a small story scale while also building value in a tangible way.
Pull out your grammar books.
Locate the adjectives in your user stories. Do you see the words “easy,” “flexible” or “fast?” Those are sure signs that this story will need to have more definitive parameters. Now look for those conjunctions; “and” and “or” are good indicators that your functionality is for more than one feature. It’s also another great conversation starter that will lead to smaller stories, hopefully with very little sentence diagramming needed. Sentence diagramming = more wine.
Take the path less chosen. And the other ones, too.
When examining a story, make it a habit to identify happy paths and unhappy paths through the story’s flow. For instance, consider the following user story:
As a forum member, I need to be able to log in so that I can participate in the forum community.
It’s time to get your QA hats on and think through some test case scenarios. First, identify a happy path:
When I enter the correct username and password, I successfully log in and I’m taken to my member dashboard.
Now comes the fun part. Let’s take off our rose-colored glasses (keep that QA hat on, it looks cool with your Star Wars t-shirt) and consider the unhappy paths a user could take:
When I enter an invalid username and password combination, I see a validation error.
When I enter an invalid username and password combination more than three times, I am locked out of my account for 24 hours.
If I can’t remember my username, I can click on a link to recover my username.
If I can’t remember my password, I can click on a link to reset my password.
As you continue to think out ways that the feature can fail, you will uncover paths that are ripe for becoming their own stories. In the list above, which unhappy paths do you think lend themselves to separate stories? If you’re still not sure, see the next tip.
Testable is the best-able
If you’re struggling to break a story into meaningful, smaller chunks, consider the last letter in the INVEST acronym: Testable. When teams are faced with a large feature that is difficult to parse, ask them to break it into testable units. This will give them a new way to view the work and will naturally lead to smaller stories.
If you don’t know, now you know
A final tip: embrace the unknown. Planning Poker® and backlog refinement tend to make teams feel required to walk away with effort points on the books. It’s important to foster an environment where your team feels comfortable admitting when they just don’t know what size the story is. “I don’t know” could be the first step to properly sizing stories that carry potential pitfalls and unknowns.
Hungry for more tips on sprint backlogs and planning? Check out more from planningpoker.com.