Why Does (Story) Size Matter?

Posted Dec 8th, 2015

When writing a user story, you need to think more like Dr. Seuss than Stephen King. You want user stories to be easily consumable, like Green Eggs and Ham. You don’t want a user story on the level of Under the Dome. If you discover your story’s duration will span more than one sprint, your story is too big.

But I Love Long Stories!

If you are a reader like me, you love to become immersed in a novel that can take weeks to read, and when you love a story, there is nothing worse than realizing you are about to come to the final chapter. I look at novels like Under the Dome, and I’m reminded of old school waterfall development. Lately, series writers seem to be following a more agile approach with trilogies. Think Hunger Games, not Lord of the Rings in scale. Who else likes long stories? Developers, who like deep investigation and experimentation for a new feature. This tends to occur at the beginning of a project when the feature infrastructure is developed, but can be pervasive throughout a project. Let’s face it — Isn’t it more fun to show a fully completed feature, with all the bells and whistles? Showing off your work at the end of a sprint can be humbling if you don’t have something visible and flashy to show for your efforts, which can happen quite often with two-week sprints.

It’s Not All About You

To those of you who like those long stories, it’s not all about you! Longer stories affect me and others on the project, from Scrum Masters planning and reporting on sprints, to team members like designers and QA. Let’s look at some scenarios:

  • Planning Poker - Let’s start with planning the sprint. Planning Poker is a great way to determine if your story is too big. Normally a small story is easy to estimate. Poker values are at the lower end of the scale for all participants, and true deviations are easier to spot. If you have a large story, your numbers can be all over the scale. There is a big difference between a 3 and 5 estimate versus a 13 and 21. Estimates will become more consistent and reliable as stories shrink. Planning Poker is a great tool for teams to use when they are not co-located.
  • Risk - Hand in hand with planning is the amount of risk assumed. If you have a small story, the risk is easily identified. Even better, the feedback loop to communicate the state of the risk is encapsulated within a short period of time.
  • Backlog Grooming - It’s much easier to plan the work in a sprint if the stories are small. Ideally you would want to pick the longer stories at the beginning of a sprint. But even then, the stories can be small enough that they aren’t daunting. And they can potentially be avoided when developers pick their next tasks.
  • Acceptance Criteria - It’s easier to identify the acceptance criteria for smaller stories. If you start seeing a lot of acceptance criteria for a story, it may be a good idea to break the story down.

Give Credit When Credit is Due

Sprints are planned based on sprint story points. Previous sprint accomplishments are accounted for by the number of story points completed in each sprint. After a few sprints are completed, a Scrum Master has a good idea of the capacity of the Scrum team. Many teams do not consider the story points for a story that is not completed in a sprint. If the story carries over, the points will as well. For example, let’s say a story is estimated at 5 points. If the story carries over, the 5 points are credited in the next sprint when the story is complete — the theory being that this will balance out over sprints and still provide an accurate baseline for planning. If stories are small enough, this will eliminate much of the sprint crossover from occurring and allow credit to be applied for work done within the sprint. Here is a good conversation about Scrum Effort Estimation and Story Points.

It’s All About Me

While all of this points to smaller stories, it’s really all about me — QA. (Ok, I’ll include you designers as well.) But seriously, long stories are the bane of our existence! QA really gets screwed when you have long stories. Let’s take a look at the lifecycle of a story:

  • The story is accepted into the sprint
  • Subtasks are added
  • Team members pick up the subtasks to work
  • QA develops tests based on the expected outcome of the story
  • Development is initially completed on the story
  • Design performs reviews of this work and makes changes
  • Dev goes back to complete the story based on the changes
  • QA re-writes tests based on the changes
  • QA is completed and the story is considered complete

Image source: http://sdc.net.au/media/1189/agile_lifecycle_large.png

Image source: http://sdc.net.au/media/1189/agile_lifecycle_large.png  

From a designer’s perspective, if nothing is available to review for multiple sprints, there is a higher probability that the product won’t match what the designer or design team is looking for. It might be well designed, but when they see it in action, they may decide it’s not the right way to go. Not only does this delayed feedback impact the project timeline, but the designer now has a lot more to absorb then a simple two-week sprint’s worth of work might bring. The same goes for QA. If QA writes tests in anticipation of a small story, they can easily be modified. The longer a story takes, the more tests will exist to be modified based on design changes. While a developer might only have to make minor changes to code, QA has to account for the full story to react to the changes. But the worst thing is that even without changes, multiple sprints’ worth of work hit QA all at once!

Size Does Matter

No matter what you might read telling you otherwise, SIZE MATTERS! Keep your stories small! Joe Nolan (@JoeSolobx) is the Mobile QA team lead at Blackboard. He has over 10 years of experience leading multinationally located QA teams, and is the founder of the DC Software QA and Testing Meetup.

Written by

Joe Nolan


Agile Development