Scrum Misconception #3 – You Have to Know Every Detail to Size a Story

Estimating work is helpful for managing teams and planning for the future. But working through every nuance to provide an estimate can cause frustration and be time-consuming.

Have you experienced a situation like this?

1. You introduce a story to a team, and you all have a nice conversation about what the outcome is.
2. You make the call to size the story.
3. The team has all kinds of questions. Then they have more questions. And a few more.
4. They size the story.
5. You realize that at this rate, you’ll only size four stories, and you’ll need another meeting to finish sizing more stories.

The problem with this is that you’d rather have your team know enough to get started and then spend their valuable time actually working on something that will become tangible, instead of spending all of those hours in meetings. Your team would really prefer that, too. (You’ve probably heard them say there are “too many meetings.”)

It’s Not About Having All the Answers

It’s comforting to believe that all of the questions have been asked and all of the answers are known before you size and start to work. But even after many details have been discussed, questions always (and should!) come up after work begins.

Sizing doesn’t have to focus solely on how much work it will take to get the job done. It can also be about risk and uncertainty. I like to remind teams that it is okay to include uncertainty in the size, and that the details will become clear once work is underway.

Some teams believe that once a story is pointed, that’s it, but I believe a more fluid approach is beneficial. I tell my teams that if they learn details that will significantly alter the size of a story, we should have a conversation. Depending on what they uncover, there are lots of things we can do, and pausing to figure out what makes the most sense is good practice.

Two Approaches for Faster Sizing

Team sizing

1. Remind the team that they are sizing based on outcomes, not on the details of the work it will take to meet those outcomes. Discuss the outcomes of each story for a limit of three minutes. As you’re doing so, write all the story titles on stickies, and post them on a wall.
2. Ask the team to line up and silently circle through, one by one, organizing the stickies from smallest to largest (easiest to hardest, most certain to most uncertain, etc.). Give everyone three turns to move one sticky note each time.
3. Ask the team to confirm as a group that the order seems appropriate.
4. Pick one story in the middle. Ask, “Is this story an 8?” Once you’ve settled on a number, ask them to size everything smaller (easier, more certain) in relation to that number. Then do the same for the larger stories.

Pair sizing

1. Spend a few minutes discussing the desired outcomes of each story.
2. Ask team members to pair (this works really well with 1 QA + 1 Dev), and let each pair take “ownership” for a few stories.
3. Give pairs 30 minutes to discuss their approaches, concerns, etc. and to size the story. The pair work can be done at the conclusion of the meeting.

Sizing Best Practices

If you experiment with your approach with sizing, here a few important points to keep in mind:

• Try time-boxing your planning sessions and sticking to those guidelines, or try a Lean Coffee-style meeting for story discussion.
• Remember that it’s okay to discover the answers over the course of the sprint and while the team is working.
• Run each new activity as an experiment, and give the team a few rounds to get into the experience. It will feel uncomfortable at first, but it should get easier as they continue. When the inevitable discomfort arises, resist the urge to revert to the old way. Remind folks that the idea is to get better at it over time and that estimates can change mid-sprint if new information comes in that changes things drastically.
• For those individuals on your team who want to point to how Scrum “is supposed to happen,” review the Scrum Guide (perhaps even as a team!). It doesn’t say anything about how sizing happens or what should be considered when sizing—only that estimates are necessary.
• Make sure that for the experiment sprints (and beyond), all relevant team members understand that quick responses and follow-up are a top priority in their day. Uncertainty can work in estimating as long as answers can be found when you need certainty.
• Make sure the Scrum master and product owner understand that part of their role is knocking on doors and doing whatever needs to be done (quickly!) to keep the team moving forward. A two-hour turnaround time on answers should be an exception and not the norm.

You may also want to encourage your team to estimate with imperfect information and experiment with finding the details during the course of the sprint. The more they do this, the better they will get it at it–and the less time they will spend trying to gather details to pinpoint the size of a story.