In this article, we’re going to explain a common phenomenon we’ve observed around losing relativity of the sizes of the stories in your backlog. This is an antipattern that could lead to your team feeling a sense of pressure because despite your productivity having improved, the numbers do not show that–thus raising a concern among stakeholders.
What is this antipattern?
If you’re on a long-running project that carries over multiple months or even years, your team begins to gain familiarity with the tech landscape, the domain, the environment in which they work, and the actual work they are doing. Over time, your ability to get work done improves. However, the velocity does not reflect that (and we’ll get into that). There is no data to match your feeling of getting more productive or effective. The velocity numbers remain similar or dip or oscillate.
The root of this antipattern lies in incorrect sizing. The current sizes are not in sync with the relative sizes that you originally came up with, say, 6 months ago and that is why the velocity doesn’t reflect your improved productivity.
Explaining it with numbers
Let’s do some math here. Six months ago, you could complete 10 “medium” sized stories (2 pointers) in one iteration and so, your velocity was 20 points. Now, say you’ve got twice as productive at doing this work so you are able to do 20 “medium” stories in an iteration. But because of your familiarity with the application you size these “medium” stories as “small” (1 point) stories. The net effect is that your velocity will remain 20 points.
The velocity doesn’t show your improvement because your story sizes are not relative to what you started out with.
Understanding using an analogy
The analogy of a pizza works well to understand how we end up messing with sizing. As a child, you were barely able to finish a small pizza. As a teenager, you could easily devour an entire medium-sized pizza by yourself. Did the pizza size change? No! The 6-inch pizza remained the same. What changed was your appetite and ability to eat pizza.
Connecting that to stories, the size of the story remains the same from what you’d estimated 6 months ago. Now, it seems smaller because of your enhanced ability. In your mind, a 2-pointer now feels more like a 1-pointer.
The “How big” and “How fast” get mixed up, leading to the antipattern
To understand the “why”, we’ll revisit the process of story point estimation. Time-based estimates go wrong because they ask one compound – and incorrect – question: “How long will this take?” Story points replace that with 2 meaningful questions: “How big is this task?” and “How fast can it be done?” And then answers each question independently.
The errors in sizing and losing the relativity of the sizes occur because the teams start to mix up these two questions. Something seems smaller (and easier) than before, not because it is indeed smaller, but because you’ve got better at doing it. The distinction between the two questions and the objectivity of each are lost.
This mixing up questions happens when teams begin to consider only the current set of stories or the most recent ones during the sizing exercise. Stories done in the past are ignored. The real meaning of a 1-pointer is lost. It had a certain definition 6 months ago, but that changed over time, leading to this antipattern. And when clients do not see any improvement in the velocity numbers, they get restless: “You’ve been on this project for such a long time. What do you have to show for it? How do we get to see that your productivity has improved?” As you grapple with these questions, you find yourself stuck in the whirlpool of pressure and self-doubt – those same negative behaviors that we said don’t happen with story point estimation.
Ways to avoid this antipattern
Maintain a set of reference stories as examples of what Small, Medium, or Large stories look like. That way, when you get a new set of stories to estimate, you will not lose sight of the older, original sizes you set out with. You will avoid downsizing and your velocity, too, will reflect the correct picture. The improvement in your productivity will get its due visibility and appreciation.
This practice leverages a key benefit of story sizing, i.e., speed. Comparing your new stories to a reference and then bucketing them is a quicker process because you don’t reinvent the wheel of what a 1-pointer is with each new set. You could change these reference stories as needed, so long as you are diligent that they match the original sizes.
Display the reference stories prominently in the team area on a wall. Make it a habit to carry out estimation around that wall. This will also work well while onboarding new members into the team’s estimation exercise. All they will need to do is understand those reference stories and their sizes well enough to start contributing immediately and productively to estimation.
With reference stories, you will put into place a sure-fire method to eliminate errors in sizing and to maintain the relativity of the stories in your backlog. By displaying them such that they are the focus of every estimation exercise, you will establish a best practice to avoid this antipattern.