Why sizing user stories will save you time

If you are working in a Scrum team, it is often necessary to know how much work is required to deliver each story you’re bringing into a sprint.

You are likely to be tracking your velocity; that is how much work you are delivering in each sprint, and understanding the size of user stories can help your team estimate how many stories they can deliver in a sprint.

As well as helping you to not over or under commit to work, estimating the size of a user story has an additional, and in my opinion, much greater and more tangible benefit. By asking each person in the team to estimate how much work they think is involved in delivering a story, you open up the discussion about what that delivery really involves, and that in turn will help you deliver faster.

Before I give an example of how this can work, I think it’s important to understand the most efficient way of quantifying a story’s size.

It is tempting to estimate the amount of effort required to deliver a story in hours. Hours are, after all the way we measure our working day. We know how many hours we work and we feel we can calculate how many days, or parts of a day, a piece of work may take. Unfortunately, this time-based estimation is also incredibly inaccurate. There is lots of evidence to show that us humans are all awful at estimating work by any metric.

So what hope is there? Well, the way, we seem to be the least bad at estimating, is when we’re considering relative sizes. A great example of this is when thinking about the size of breeds of dogs; we all know a Yorkshire terrier is smaller than a Labrador and a Great Dane is the biggest.

Now imagine for a moment using this kind of sizing instead of a time based sizing for the effort required on a user story. You can think of the smallest user story you’re likely to deliver as a Yorkshire Terrier and the largest as the Great Dane.

I have worked in teams where we have estimated stories this way, with pictures of dogs on cards that we each hold up. I’ve also used modes of transport, from scooter to bus and t-shirt sizes, from xs to xl.

This relative sizing, while not perfect is much more accurate than time estimations.

The most efficient version of this relative sizing is when you replace the dog breeds with the numbers from the Fibonacci sequence. The possible sizes then become 1, 2, 3, 5, 8 and 13. Of course, you can go higher but it is rarely a good idea to take on a story bigger than this as it is unlikely to be completed in a sprint of work.

I recently bought a set of “Planning poker” cards from Amazon with the Fibonacci sequence numbers on them, and after removing the numbers higher than 13, I hand these round at our planning sessions.

Now that we have defined a best practice way of sizing stories, I would like to get back to highlighting how the sizing of stories opens the conversation between team members as to what effort is really required to deliver a story.

The following example is typical of a sprint planning meeting in which a solid understanding of the effort required is really understood:

• The entire team assemble to plan what to work on next. This includes any developers, testers, devops, designers, and any other person on the team.
• The team review a user story and check that they all understand the problem to be solved. Together, they review the description and acceptance criteria, changing anything they feel needs amending until everyone agrees they know enough to size the work.
• The Scrum master counts down from 3 to 1, and everyone in the team shows a card with how big they think the work is.
• Most of the team show the same number, but one person shows a larger number and one a smaller number.
• These two people then take it in turns to explain why they chose that size. For example, a tester may have said a larger number than the rest of the group because they are aware that getting test data to allow testing of the functionality is a lot of work. A developer may have shown a smaller size because they are aware of some very similar code that can be enhanced to provide the new functionality.
• The discussion continues until everyone is happy they once again know enough to re-estimate the size of the story.
• The Scrum master counts down again, everyone shows the card with their new estimates and there is a consensus across the team.

This is the flow most planning and refinement sessions I attend follow. It leads to the most accurate sizing of stories I believe you can hope for but most importantly, it facilitates communication between the group members.

This improved understanding of what needs to be done before any work is started help:

• Reduce time wasted building the wrong thing
• Improve how the team organise themselves to get the work done
• Highlight any impediments or blockers early.

All of which, speed up how fast you can deliver the story.