“E” is for Estimate
Today’s article is brought to you by the letter “E”. Estimates are estimates and they are always wrong. I love the image above because I feel stakeholders have this look when receiving estimates and developers have this look while creating them.
A Little Background
It’s common for Agile Scrum Teams to use a “Planning Poker” exercise to determine estimates. There are alternative solutions that may be used as well. Scrum Teams could decide to use “T-Shirt Sizes” (S, M, L, XL, or XXL). The use of Fibonacci numbers is probably the most popular method.
If you ask the average person to rate a meal, they will give you a number on a scale from 1 to 10. However, how do you really determine what's the difference between a 3 and 4 or a 7 and 8? This is where Fibonacci numbers come into play. Fibonacci numbers have enough difference between their values that deciding which value to pick becomes less of an issue. Now, if you ask someone to rate the same meal using numbers like “0, 1, 2, 3, 5, 8, 13”, then it becomes a lot easier to choose a rating. This is because there’s a greater separation between options as the scale increases ( note: I’ve seen teams skip choosing 2 unless it was a special scenario).
My personal favorite is a hybrid approach of combining Fibonacci numbers as the values to use while “Planning Poker”. This 3 min video explains how to use “Planning Poker” in your Scrum Teams to do estimates (note: Miles may vary per Scrum Team. Everyone does it slightly differently which may lead to different results.)
So what “E”xactly is the Problem?
We have to talk about “E”xpectations vs Reality to really answer that question. Let’s first put the focus on stakeholders. They typically ask for estimates but they don’t treat these estimates as actual estimates. They typically treat them as hard deadlines and this is problematic. When you are primarily focused on story points delivered vs. value delivered, you are inherently setting yourself up to always be unhappy. The more story points your Scrum team delivered does not translate into more value delivered.
Imagine a scenario where your Scrum Team doesn’t value assigning story points to bugs and defects. However, fixing those bugs and defects increases customer satisfaction and improves the quality of the product. In this example, you delivered fewer story points while simultaneously delivering more value to the customer.
Not only do stakeholders have a tendency to view story points as hard deadlines, but they also have a tendency to associate story points to a value representing a number of hours versus the relative level of effort. The following 4 and half minute video explains this point pretty well.
Now, let's focus on the developers who are responsible for coming up with the estimates. There are various reasons why “e”stimates may be wrong. First, it’s important to understand the nature in which these user stories are presented; and what’s going on in the head of the person who is providing the estimates. Here are some scenarios to consider:
- Biases lead to conflicts. Each developer could be thinking of a different solution that will vary the level of effort to do the work. So their estimates will vary. Personal bias and company politics can sneak into the discussion to resolve this conflict. This can result in an estimation that never should have been made in the first place.
- New features vs old features. If the feature that needs estimating is new to the team, it will most likely be higher than the second or third time than when they will need to do it in future sprints. So how do you decide which estimation is correct? Is it how the story was estimated the 1st, 2nd or 3rd time?
- Not based on a previous estimations. Story points should really be assigned based on the level of effort of other features. So if your using Fibonacci’s numbers and are confident that Feature A was a solid “1” and Feature B was a solid “5” then the team should use their knowledge about Feature A and Feature B to determine other features’s estimations. It becomes very easy to provide estimations that don’t make sense when you are not using previous esitmations as a point of reference.
- The Team changes. 99% of the teams I’ve been on have added/removed developers within the first two months and definitely every 3 months. Even if your team gets in sync by providing relatively good estimates, the team can get out of sync once the team size changes.
- Fear of the unknown. Estimations increase with respect to the level of doubt of the developer who’s responsible for providing an estimation.
- Poor understanding of what’s needed. This may be as simple as the requirements are unclear but someone still provided an estimation anyway.
- The weakest link. The strongest developer for the task may not be the developer that actually ends up working on the feature. The strongest developer might be the person who is the most familiar with the nature of the feature and has the most background to what’s involved in the solution. This is moreso has to do with domain knowledge than it doesn’t programming skills. The weakest link on the team may end up putting in more effort to do a task than a stronger developer would solely base of lacking information about the task. You can think of it like a bodybuilder lifting weights. A child would need more effort to do the same weight that a bodybuilder would use to lift the same weight.
- Not ready! A feature should have never been estimated in the first place. This could be for various reasons like a missing design file attached to the story or just requirements that were never approved. Once you pulled a feature into your sprint you are committed to delivering that work. In this case, your estimate is wrong because you discovered late that the level of effort was inaccurate due to hard dependencies that still need to be resolved.
- Element of surprise. A lot of times, the sprint planning meeting is the first time a developer is viewing the feature details. Developer could provide better estimations if they had adequate time prior to the Sprint Planning meeting to review the stories.
- Fatigue. Sprint planning meetings can easily end up being two hours long. Developers will become fatigue, their attention span begins to fade and they just want to get the meeting conclude as soon as possible so they can get back to work. They will eventually hit a threshold where they are just creating estimates fast, so one exists, and they can move on to the next feature to estimate. The consequences of rushing gets passed on during the sprint by whichever person ends up working on the task.
Summary
There are a lot of moving pieces that result in poor estimates. When you combine stakeholders' perceptions of story points combined with everything developers deal with while estimating story points it leads to inaccurate and inconsitent estimations. When you don’t have a work culture that addresses these issues it will always create a perfect storm of inaccuracy.