The Importance of Understanding The Work Estimation
The Importance of Understanding The Work Estimation
Avoiding Common Pitfalls to Achieve Accurate and Reliable Estimates
When it comes to estimating the work, I have seen many teams doing it wrong or in a very complicated way. Additionally, I have observed a lot of discussion and controversy.
The estimation should be a simple and fluid exercise to help your team to:
Break the work into more digestible or manageable pieces.
Determine how much work they can handle in a certain period of time (e.g. a week or a sprint)
If you are:
Taking too much time or effort.
Having a lot of discussion in your team to reach an agreement.
Not considering all your team members in the estimation exercise.
These are symptoms that something is not right in your estimation process.
Consistency Is Key When Estimating The Completion Of Work Increments
Many elements must be in place to obtain accurate estimations for the completion of features, projects or work increments.
For more information on this, you can read my previous post:
The correct breakdown of work items and their estimation is one of these elements. If the estimation scale or method you choose is consistently followed, and if the chunks of work are consistent in size, then you will be able to calculate with a high degree of accuracy when an increment (e.g. a feature, a project, an MVP) will be completed.
Of course other variables come into play:
The scope must be under control.
When building prototypes or discovering a new product, you may not have clarity on when the scope will be final. However, even when the scope is not completely defined, you can determine work increments or small goals.
We Confuse Completion Time or Deadlines With Estimations of Units of Work
Yes, completing a unit of work (e.g. a story, technical task, a spike) takes time, but we should see the big picture:
A single story goes through many things when it moves through our workflow:
It competes with other user stories and tasks. The team may be switching the context to work in higher priority tasks.
It can be blocked, or the team may be waiting for something to be able to complete it.
The team may be passing through a difficult situation with the lack of team members, bad team morale or unbalanced skills.
The team is not 100% focused and always working. They need to take breaks.
Some team members are more experienced and skillful than others. Or the combination of skills in the team are enough to consume those stories.
Some people may fall into the trap of asking the team for the individual units of work:
When will you complete this work item?
How much time will this item take?
We should focus on the size instead.
Let me give you this example which I hope will help clarify how important is not to confuse units of work time completion with units of work size.
When you order a pizza, the shop may offer small, medium, large or extra large sizes.
What Criteria Do You Use to Order Enough Pizza and Their Size to Satisfy the Number of People Attending a Party?
Here some ideas:
How many people will attend the party (e.g. 3 to 9)?
The duration of the party (e.g. Two week iteration)?
Historical or anecdotal data on how many pizzas a crowd like this or an average individual can eat (e.g. 2 large user stories, 3 medium user stories, and 5 small ones? or 50 story points per the last 4 iterations?)
Are the attendees adults or kids? (e.g. is it a team of senior developers?, a mix of junior and senior?)
Flavor preferences: carnivores, omnivores, or vegetarian (e.g. team members' skills and experience, front-end, back-end, QAs, SREs, UX/designers)
You may come up with something like this combination of pizzas:
Three extra large pepperoni (e.g. Three extra large front end stories)
Two large Hawaiian (e.g. Two large back end and SRE technical tasks)
And three small vegetarian (e.g. Three small UX/design tasks)
Overtime, we should be able to calculate with a high certainty, the amount of pizzas our attendees will eat. But a key element here is the size of the pizzas, we need to make sure they are consistent in size.
The size of the pizza remains constant regardless of how fast each individual eats it.
But which estimation methods and techniques should you use to estimate properly?
The Estimation Techniques I Have Employed
I cannot tell you what estimation technique will be the best for you. I will tell you what has worked for me under my experience and I invite you to try it yourself.
The Fibonacci sequence
The Fibonacci sequence as described in this article is:
A scale that uses story points that grow exponentially on purpose. If the points were assigned sequentially (e.g. 1,2,3,4,5,6...), there would be a lot of discussion around determining the correct point value for each work item.
“Each number is the sum of the preceding two numbers: 1, 2, 3, 5, 8, 13, 21…”
The points are a mixed representation of: “complexity”, “effort” and “uncertainty”.
Important: You may notice that we do not refer to time or number of hours as the complexity and uncertainty factors would make very difficult to create a meaningful and consistent scale. What a team is typically able to do, is to determine how many tickets of a given size (or a combination) can be taken during an iteration (e.g. the number of pizzas in our party).
This is an example of the scale and language I use for my teams. You can figure out your own scale that your team may adopt:
1 Pt. = Simple complexity or no complexity and definitely no uncertainty. The team members know exactly what to do. It is a trivial effort in every sense.
2 Pts. = Some added complexity. Although the teams know what to do, the efforts is not as trivial as the last one. They can visualize the entire solution before starting though.
3 Pts. = There are some added complexity, uncertainty and effort. The team knows where to start and what to do, and they are confident the parts in the middle will become apparent as they have done this in the past or they have faced similar challenges like this.
5 Pts. = More complexity, uncertainty and added effort. Although the problem is clear and the team knows where to start or end, they are unsure how to get the solution. The team does not do this very often or they need help from others.
I recommend my teams to not take too many tickets of this size since it may be easy to overflow our capacity during an iteration.
8 Pts. = There is more complexity, dependencies, effort or unknowns that the team is comfortable with.
I typically do not recommend my teams to take a work item with an estimation like this, since this is an indication that the problem or work needs more investigation or definition and will likely need to be broken up into more stories or need a Spike before taking it.
13 Pts. or beyond = Whenever the team estimates something like this big, it is evident that the work needs further definition or research. Typically this may be an epic, a large feature, that needs to be broken into more digestible pieces or a problem that require multiple spikes, research or run proof of concepts.
As you may imagine, we never accept a work item like this big in an iteration. But we take actions to make this more digestible.
The Common Flaws of This Technique
I have seen some teams separating the development and QA points and then, adding them altogether to estimate a work item. Or some teams also “estimate” the Dev and QA points separated to be able to calculate their capacity in separate as well.
This is misleading as we need to remember that a team should be cross functional, everyone should be able to help each other and collaborate to accomplish the goals of the team. Therefore, the work estimations should include the opinions of all the team members.
Calculating and maintaining the right balance of skills to complete the work assigned to a team is a topic that should be covered in a separate article. But, it is a fact that if you don’t have the right balance of skills, this will complicate your work estimation and capacity calculation process and ultimately it will impact the delivery of work.
So coming back to our Pizza shop example, to clarify why we should not split the estimations by role or by “sub-teams”:
Let’s assume we are on a Friday night and we have multiple orders coming to our pipeline. We want to make sure we have enough staff available to be able to complete all the orders.
If we just considered in our units of work size estimation (Pizzas) just the effort to cook them but we did not consider what is required to package and deliver them to the client, most likely, we won’t be successful.
So How Do We Estimate in a Cross Functional Team?
This is how I would recommend to do it:
Scenario 1: Story that is somehow complex in Dev but trivial for QA
Dev team members vote as 3 story points
QA team votes 1 story point
What would be the overall estimation?
3 story points considering all points of view. Dev + QA team members.
Scenario 2: Story is trivial for dev team members but is more complex for QA.
It is a one line change for dev team members and it is pretty easy so they vote a 1 story point.
However, QA needs to recreate the scenario and is very complex to test, they may say it is a 3
What would be the overall estimation?
3 story points as well, considering all points of view. Dev + QA team members. In this case, QA moved the needle and caused the estimation to increase.
Scenario 3: A technical task such as a test automation. That is typically done by the QA team members only.
Dev team members do not vote
QA votes as a 2
What would be the overall estimation?
2 story points, even though Dev + QA team members are considered in the conversation. The dev team members will not vote as they do not have context or the ability to implement this.
Ideally, the dev teams should be able to help and contribute somehow, but in reality, we will face a situation where some work items can be done only by certain team members with a specific skillset. Which is fine, we just need to be very careful to balance the work items that are being added to an iteration by assessing the combination of skills and capacity available.
Note: If we find out ourselves in a situation where our capacity is segmented or blocked by the lack of a skill, we need to reassess the team composition or figure out how we can create a real cross functional team.
Using our pizza shop example: We can have too many chefs in the kitchen but not enough delivery people to deliver all the pizzas we produced.
T-Shirt Size Estimation
This is my favorite estimation technique. By using objects, you eliminate the temptation of your teams to “sum points” or separate story points by dev or QA team members. As well it makes the estimations less ambiguous and it is simpler for your team to choose from one size or the other quickly.
You don’t need to use T-shirts. You can have some fun and use burger sizes like: Quarter Pounder (L), Big Mac (M), Double Cheese burger (S) and cheese burger (XS) or use any other scale meanwhile your team adopts it and consistently uses it.
You can use the same scale and criteria I showed you before with story points but using T-shirt sizes:
XS = 1 Pt
S = 2 Pts.
M = 3 Pts.
L = 5 Pts.
XL = 8 Pts.
XXL = 13 Pts.
I noticed that the longer my teams worked together, the more and more they were consistent on estimating and breaking the stories.
I found when I ran some metrics, that my teams in average worked on work items similar in size ( ~2.5 story points ). So it was easy for me to estimate the completion of a feature, an increment or a project by using the number of work items remaining in the backlog and the average throughput.
Which pushed me to explore the no estimates movement.
No Estimates
If you Google the “no estimates movement”, you will find very interesting information.
I liked this article I found: “The logic of #NoEstimates”
This one explores why no estimates still makes sense in the Agile and Scrum world.
Quoting:
“The team is becoming so predictable that it doesn’t make sense to use story points anymore. A team knows how much it can chew without requiring story points.”
You can estimate the completion of an increment or a project by counting similarly sized work items such as stories, technical tasks, and spikes created by the team.
And this podcast: Your Estimates Suck was an eye opener for me as well:
Shape Up is a development approach that aligns with the no-estimates movement. In Shape Up, teams are given a fixed time frame to deliver a meaningful solution. This necessitates scoping the work to fit within the time frame.
This type of development is characterized by its speed and close collaboration between team members and product stakeholders. As work progresses, tasks are broken down or elaborated upon as necessary. Shape Up is often employed by start-ups or teams with limited time and budget, who have the freedom to shape the scope of their work to achieve their goals.
Conclusion
Whatever method you choose, it is important to be consistent and do not mix concepts like work estimations, capacity planning, team’s skillset combination or deadlines. They are not the same.
If used properly, they all can help us estimate the completion of an increment or a project with a high degree of certainty.
Hope you enjoyed this article! Let me know what you think in the comments. If you're feeling generous, you can buy me a coffee to fuel my writing!
Share this article if you liked it:
Subscribe to receive more posts:
Hello! Very detailed post, thank you. I implemented the T-shirt sizing metric with success some years ago. It's easier for the team to apply by simply comparing the ticket size to others. Nevertheless, I still needed to transpose the sum of the t-shirt sizes to a quantifiable number. What I noticed months later is the team started to estimate the tickets based on effort again and labeling it a t-shirt sizing. But for me, one of the most critical aspects is to have the tickets relatively smaller in scope. Way much easier to predict and manage, no matter which estimation technique is applied.