Making Estimates Work for Your Development Team

There are topics in the IT world that divide opinions: what needs to be tested, test-driven development, do we work alone, in pairs or even in a mob? Do we need estimates for tickets?

Today I want to discuss estimates and why I think they are essential in a dev team. I realize many developers see it differently because estimates have an awful reputation. Critics say that they don't bring much to the team, take a lot of time in meetings and at the end "management" gets a statement when which feature is (guaranteed) available. In the sprint, people are then also quick to talk about why a supposedly small task is taking a long time. So, we have something that costs us a lot of time as developers and makes life difficult afterward because someone converts story points into time. And sure, if that's how estimates are lived in team, then I would question them in that form as well. But estimates can also be useful, help the team and help to plan things.

For me, estimates are always good when they help to understand a problem. To achieve that, you need a stable team, some time and the following techniques:

Reference Stories

No matter how a team estimates, they should have a reference story for each story size. That is, a story that the team knows and ideally the scope of the task. Then, when a story is estimated, the reference stories should be used as a comparison. This leads to better discussions because we are comparing a task to something we already know. If the team then differs on the estimate, then you can compare the new story to the reference story. By the way, reference stories should always be questioned by the team and replaced with better ones if necessary. It is important that everybody within the team knows the story. Alternatively, you can use other stories that the team has appreciated.

Identify reference stories

When I started a new team, I always tried to identify reference stories in the first sprints. To accomplish this, we first estimated stories "by gut feeling" and then corrected the story points again after the sprint. After a few sprints, we had a good set of stories. If the team changes, then it could make sense to talk about new reference stories, too. If the team identifies a story as a good reference story after the sprint (maybe for a different estimate), then you can use it as such.

Don't estimate for others

When it comes to estimating, first someone presents the story (it doesn't have to be the product owner) and then everyone gives their own estimate. Three rules are important:

1. everyone estimates based on the reference stories.
2. it is not about time (more about that later). It's about which reference story fits the new story in terms of complexity.
3. everybody estimates for themselves personally and not the team or the developer, who would do it very fast.

It's okay if the backend developer estimates a task with more story points for the frontend story or the new team member picks a higher number because they don't know everything. This shows that there is a certain risk because some people see this task as more complex than others. This still helps in estimating the task.

Sometimes, story points are very close and you can agree on a number. This is a good indicator that everybody has a similar understanding of the task and there is no need to talk about the complexity. Sometimes, you see significant differences and this is, when it comes to the most important part of the session: talking about estimates.

Talking about estimates

Usually, this starts with the people with the biggest and lowest estimate sharing their reasons for picking the story points. Now the team can talk about complexity and what are the important things for the story (or, if there is no big difference, agree on a number and go on).

After all, this is where it often becomes clear if someone perceives a problem as too complex or someone didn't fully understand a story. The team can then discuss the scope of the story, ask clarifying questions, and add to the story accordingly. Often, the person presenting the story can also make minor adjustments here to ensure that a topic is implemented as envisioned.

After that, you can estimate one more time, and maybe you already have a similar estimate. If only certain people in the team can implement a story (that's a topic for another article), then you can pragmatically note that for now (as long as not every story is directly assigned ... but yes, other topic). If there is still a big difference, there are open questions, and you should clarify those.

Sometimes, you cannot find a common size. In this case, maybe the person who introduced the story can change it in a way that allows you to work on it in the next sprint (perhaps you want to do a Spike on the topic, might be you can start with a small subset of the original planned features...). The important learning is, that you identified some problems and now is the perfect time to address them.

For me as a developer, estimates then already served their purpose. Maybe it would be best to lock the numbers away now because we still have the problem with the time that can be derived from story points. But perhaps, we can improve this, too?

1 story point can't be converted to time, 30 possibly can.

One thing first: it is totally nonsensical in my opinion, in a new team or after adjusting the way the team estimates, to derive any times from estimates. A story point can represent a straight-forward but time-consuming task. If a team has a velocity of 30, it may manage 40 stories that are one story point in size, but only one story with 20 story points.

When we discuss timing, the first requirement is that the stories are not too big and not too small. If you look at the story points of a story and when they were solved during the sprint, you can quickly see if they were done evenly over the sprint (optimal) or before the review (not so good) (burn down diagram). In my opinion, it is the task of the product owner to find the right mix with the team so that, ideally, value is delivered continuously.

After a few sprints, the velocity of the team becomes apparent. In my previous teams, this was the case after about 6 sprints of 2 weeks, but it can also take a little longer. If I know the velocity, the product owner can also make predictions when (estimated) future stories can be delivered. This is some mathematics coupled with a certain buffer, so that a deviating sprint (vacation, illness or a bad sprint) does not immediately throw the entire planning over the heap.

Bonus content: quick to a rough estimate.

When I need to estimate in a new team, I use a formula for a rough estimate: "number of areas I need to adjust" * 2. An "area" is something like frontend, backend or infrastructure. So an area where changes are needed. A pure frontend story is more like 2 story points, if I also have to do something on the backend and on the infrastructure, I pick something around 6 story points. If an area is particularly complex, I count it twice. This is a milkmaid calculation that only serves as a first rough estimate. I ignore the factor time and focus on complexity here.

It is all about your environment and context

The approach I describe here only works in a trusting environment where everyone is interested in delivering value and the pressure to plan everything to the minute is manageable. I find estimates good to have a basis for discussion so that we have the same understanding in the team and can avoid misunderstandings early on. In environments where estimation makes your own work more complicated, I would think about doing a slimmed down form of estimation in the dev team: talk about the complexity of the next stories and which stories you know that were comparable.

How do you handle estimates in your team? If you don't estimate, how do you ensure that, the important discussions are held? Feel free to sent me a message on Mastodon

PS: I use the terms Sprint and Product Owner here, but the whole thing is not limited to Scrum.