Why do we estimate and can we do without?

Trying to find a way of being more predictable. Part 2

One month ago I wrote an article about estimation anti-patterns. It all started off with a delayed release, followed by a message that we need to become more predictable, followed by a wild idea of removing story point estimation.

Once the idea was in the air and started getting momentum, we had to figure out what we would actually lose if we were to move away from story point estimation.

Last summer we had an offsite with 5 teams from XING, all working in the same area. There I’ve pitched an open space session about estimation and #noestimates experiment.

The open space group consisted of Product Owners, developers, QA folks, UX and visual designers — a well rounded crowd. It gave a fairly comprehensive picture of what both “consumers” and “producers” of the estimation process expected to gain out of it.

We started the session with a question — Why do we indeed estimate?

Once all of the points were gathered, we went through each and every one and tried to figure out whether it was possible to meet the same need having removed estimation process.

1. We estimate to understand if the user story needs to be broken down

One of the benefits suggested by the “producers” of the estimate. When using story points with planning poker ritual it was indeed easy to understand if the story had to be broken down further. In all of the three teams we have established a threshold of story points above which the story had to be broken down. In one team that would be 13 story point. If the team estimated any user story with anything higher than 13 story points, the user story had to be broken down further.

Can we find a way of deciding if the user story had to be broken down without estimation? — Yes, we can.

For example, there are estimating cards that do not use story points.

Or even a simpler and more elegant solution. Simply ask:

1. Can this user story be broken down further?
2. Does it make sense to break it down further?

In case of Yes & Yes, the user story should be broken down further.

2. We estimate to see if we are on the same page

We were expecting the routine of estimation to help us establish shared understanding of the user story between product and development parties and within the whole team overall. If during a backlog refinement meeting a user story has been estimated differently by different team members or if someone has raised a question mark that would mean that we have not reached shared understanding yet and more discussion needs to follow.

Was there anything else besides estimation that would allow us to see if we were on the same page? — Yes, there was.

In the previous article I have already talked about alternative approach of building shared understanding by simply asking specific questions:

1. Can someone on the team rephrase the business value of the user story?
2. What is the technical implication of making it real?

We could use a round robin approach to make sure that every person on the team gets his opinion heard. Here is how it could have looked like.

1. Product Owner or someone else on the team presents the user story.
2. It is now Jack’s turn and he starts rephrasing business value of the story (why we are doing it) and the technical implication of it (what needs to happen in order to make it real).
3. Once Jack is done talking, the rest of the team discusses whatever Jack has left uncovered or where they disagree. Product Owner clarifies questions.
4. When the discussion boils to an end, someone, anyone of the team can ask — “Is this story ready to be taken into the sprint?”.
5. If yes — move to user story B and next person in the round robin order will start the discussion. If not — continue with remaining questions regarding user story A.

This kind of round robin approach does not address the issue of anchoring the group with one person’s opinion or leading to a groupthink a little too early. Planning poker performs much better in having people construct their own opinion before starting a group discussion. In a psychologically unsafe environment removing planning poker may not be a good idea. But in the team where people are not afraid to challenge the opinion of others regardless of the title, where people are not afraid to ask simple or “stupid” questions, removing planning poker is worth trying.

3. We estimate to let ScrumMaster know that the team is working

This was the biggest “aha” and “ouch” moment for me during that open space session. Never before did I realise how my constant talking about improving our predictability and making sure we estimate right, affected the team.

In the end estimation was and is only a by-product, something secondary, something that does not directly contribute to the end product or a service we are producing. But isn’t that simply amazing how much emphasis and importance we sometimes put into it?

If the team would meet its estimation 100% of the time, but the product that we would be producing buggy software that wouldn’t be used, I would count that as a failure. Not the other way around.

With a little sigh let’s move onto the next point.

4. We estimate to know when it is going to be done

We are estimating user stories to know when it is going to be done. We need to communicate release dates to the management, stakeholders, sales, marketing teams, other development teams that are dependent on our deliverable.

Can we know without estimating user stories when a user story or an epic will be done? — Kind of.

Before jumping into specific how here, let’s make sure that we are clear. Even when estimating we don’t know when we are going to be done. That’s the definition of an estimate — it’s a guess not a guarantee.

When not estimating user stories, we can forecast using historical data when X number of user stories will be done. For example, the team completed 10 user stories on average during the past 5 sprints. Then it will be able to deliver approximately 30 stories in 3 sprints. That is again only an educated guess.

During that open space session we have also discussed a case of having a need to provide an estimate before we have all of the stories or before having a point when forecasting is possible. Then, we agreed, we would still estimate epics using the number of sprints as a metric. We would also try to provide a range of estimates — for a happy path, when all risks are mitigates, and an alternative estimate for the case when some things go astray. We would also revisit those estimates as soon as we learn more about the domain, new technology etc.

On the side note, I learned an interesting way of managing date expectations between marketing and development teams after paying a visit to one of the Hamburg-based startups. There the teams were not estimating user stories also. Instead of the development team estimating the whole product development part and giving the release date to the marketing team upfront, they have calculated how long marketing team needs on average to prepare promoting campaigns and roll them out. On average that was 5 weeks. So now, instead of giving a rough estimate upfront, development team was getting in touch with marketing team only when they were confident that they could ship the product in 5 weeks.

5. We estimate to show that we have thought through the story

This point is pretty similar to the one of using estimation to understanding if we are on the same page.

Can we show that we have thought through the user story without estimation? — Yes, we can.

How? See “We estimate to see if we are on the same page” paragraph.

6. We estimate to plan the resources

We work in a stable team environment, not in a matrix organisation. “Plan the resources” point here was addressing cases of high specialisation within the teams. Sometimes there was not enough to do for frontend developers, sometimes for backend developers. Estimation process and discussions around it helped in coming up with a sprint scope that would occupy all parties.

In my dream world this issue would not exist because we would only have T-shaped specialists who, besides being an expert in one area, can perform some not complex tasks in the other area.

I don’t give up and still strive to bring that picture live, but in the mean time that is a real issue in some teams.

Can we make sure that all different people on team have sufficient workload without estimation? — Yes, we can.

How? By simply asking the team during the planning meeting.

7. We estimate to avoid surprises and delays

We don’t want surprises. We don’t like them. That is one of the reason’s children like commercial breaks on TV so much. They are repetitive and predictable. There are not scary or in other words there is little surprise there.

When we grow, our level of tolerance towards anything new grows. But even then, our body that is naturally wired to save energy does not like turning on the turtle mode (see Kahneman “Thinking, fast and slow”) and spend lot’s of brainpower to develop a new pattern of behaviour to adapt to the changed environment.

Can we avoid surprises and delays without estimation? No, we can’t. Most importantly we can’t avoid them when estimating either.

8. We estimate to minimise risk

It is often believed to be the case, that estimation helps in mitigating risks. Estimating and putting user stories into small, medium and large buckets helps us avoid surprises and delays.

But here’s the deal. I struggle to see how putting a label on a user story helps in mitigating the risk that is connected to it. In what way saying that something is worth 13 story points helps us to make sure that this user story will not blow up and take whole 40 story points? Estimating indeed helps to highlight risky or complex parts but all of the risk mitigation, what needs to be done to make sure that the user story does not indeed blow up, in my perspective, happens outside of the estimation world. To me the idea is so important that it deserves a separate line.

Estimation ≠ risk mitigation

The wish of avoiding surprises and delays is natural. The quality of promising and then delivering within the promised time frame is considered by very many as a sign of true professionalism. Then estimation comes into play and we look up to it as a “go-to” tool for so many different things:

1. To help us establish a contract between the team and the upper management or stakeholders
2. To mitigate risks
3. To show our professionalism by delivering on time.

Poor little estimation is overwhelmed with that much attention.

But after having another look at the estimation process, the essence of it, all that estimation does is — it establishes a connection between an object that is being estimated and a guess. A guess that is sometimes well educated sometimes not. That’s it.

Here are a few tools that could help instead in mitigating risks:

1. Agreeing with the stakeholders and upper management to re-plan when starting a new epic. Whatever the agreement is regarding the scope and time required, it is based on a huge amount of assumptions and very little amount of validated learning. Agreeing to re-plan, when the portion of validated learning will increase, helps to mitigate the risk of not delivering on time or to re-define what on time would be. There is a great report by Henrik Kniberg about phased decision making process when creating a new product @ Spotify. At XING we have a different approach to staged decision making with quarterly roadmap reviews and using an ACE or Auftragsklärung as a kick-off format.
2. Prioritising user stories or tech tasks which are maximising learning at the beginning of a new epic. This kind of approach helps to gain validated learning faster and feeds into point 1.
3. Breaking user stories vertically and as thinly as common sense allows. This way a Product Owner has a leverage to manage scope in case part of the feature takes too long.
4. Making sure that the team is getting feedback as early as possible. Not just the feedback from the users, whether the new feature is performing, but also whether the code builds, whether the code integrates, whether some piece of code is buggy, whether it performs well on production environment. Normally “Continuous Trinity” answers these kind of challenges — Continuous Integration, Delivery and Deployment.
5. Involving all team members to some extent into ideation and discovery process. There is a huge difference in the misunderstanding potential if we were to compare two teams. One that hears about the user story and the problem that it is trying to address for the first time during the backlog refinement meeting. And the other team that was involved in discovery process, was part of the story splitting activity and where all team member already have built up some level of intrinsic knowledge regarding the user story before the backlog refinement meeting.

9. We estimate to prioritise

Let’s say there are two A/B test ideas how to improve existing product. Both have equal potential of success. The Product Owner needs to figure out where it makes most sense to invest the effort of the team.

Normally story point estimation helps in answering the prioritisation question in such cases. The A/B test idea with the lowest story point estimation wins.

Can we prioritise user stories in the backlog without estimation process? — Yes, we can.

We still can have the same conversation about the A/B tests alternatives, what makes more sense to do in the beginning, simply without an estimate. Which one is easier to developer A or B?

10. We estimate to create a roadmap

We are estimating to understanding how long epic X will take. This helps us build a roadmap and communicate it to upper management and to our stakeholders. This helps us manage dependencies across teams.

Can we design a quarterly roadmap without story point estimation? — Yes, we can.

Can we design a roadmap without estimating epics using number of sprints? — Probably. We could define the most important epic for the upcoming quarter and re-plan epics quarterly.

In the end, during that open space session, I was not proposing to completely abandon estimation process, rather not to estimate user stories or anything smaller than an epic.

Take away

Useful exercise

The question “Why we estimate?” led to an interesting discussion with lots of insights. Especially in the light of understanding what kind of needs the group had in terms of predictability and how we were attempting to satisfy those needs with estimation process. We had people in the group who have been working together for a couple of years already and I bet that we all learned something new about expectations of others towards estimation.

Yes, we can!

The idea of removing story point estimation seemed quite radical to many before that open space. The more we were approaching the end of the list, the fewer concerned faces there were in the audience. I had a feeling that people overall relaxed when getting the point that estimation in itself is not that big of a deal.

#noestimates prerequisite

In the retrospect having a discussion around estimation and what kind of needs we are trying to fulfil with it, was crucial to the success of #noestimates experiment.

After the offsite one team volunteered to go on with the experiment. There was still a lot to do. We had to design the experiment together, define what we will exactly do during planning and backlog refinement meetings, define how we will know if the experiment is working out or not. But the key point was already addressed, their concerns about estimation were answered and the team was motivated to try.