As a Program Manager, I must facilitate estimates for items too early to be estimated in almost every company I work with.
Let’s not kid ourselves; estimates are needed in the modern business world, especially when you release your first version of a complex product and hit the right product/market fit on time. Of course, you could argue that the modern Agile method doesn’t work with deadlines, but I want to stop you here and say this is incorrect.
You can still deliver sprint after sprint, but releasing it to the customers for the first time in the complicated business situation where we live and operate needs a deadline to plan all the activities related to a product release.
Problem definitions:
Imagine we have a team of 3 engineering teams with a mission to build a helpful covid vaccination website, so anyone in a specific area could book a slot for them and empower the medical staff to serve them quickly.
It’s essential to have this product built by November 5th to prevent the mass gathering of people wanting to be vaccinated and to reduce the risk of contamination during the long waiting times.
The expected date for this event was taken from the national health body.
After hearing about the mission, the team decided to build their mission aligned with the product goal.
For Team Zebra:
Build a reliable platform for continuous delivery and integration, ensuring security, compliance, and quality.
For Team Lion:
Onboard the customer and Protect Customer data. Align with HIPAA and GDPR.
Team Cute Dog:
Vaccination Process End-to-end.
After each team knows the requirements, they sit with the product owner or the person representing the customer in a different setup and create the epics.
To simplify, this is how the teams decided to create their epics.
For Team Zebra:
For Team Lion:
Team Cute Dog
A trained eye will immediately see that more pieces are needed to make this product operational, but most of the time, this is the case in almost any product at that early stage. We will talk about this later.
At this point, we need more data to answer whether we are most likely to hit our deadline or if we are way off the chart and need to do something about it.
It’s similar to the Story point in Agile, but instead, on a story level, where you suppose to have all the information needed to establish the size, we apply it to an epic level where we don’t have such details.
Just a reminder that whatever system we use, a point takes into account all the factors that could impact completion:
The Fibonacci sequence is one popular scoring scale for estimating agile epic points. The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, and so on, with each number the sum of the preceding numbers.
Fibonacci agile estimation refers to using this sequence as the scoring scale when estimating the effort of agile development tasks.
For each team, discuss all the epics shortly and ask the group to think about all the factors of an epic point, which I listed above. Then ask the teams to put the epics on the Fibonacci scale. To keep it convenient for the activities later, limit the scale numbers only to 8,13,21,34.
You could start this in two ways:
If you have a small number of epics, you could ask the team to put them directly by comparing them. This is what team Lion did.
If you have many or want more precision, you could say, Epic “Test Execution” is a 21-pointer, and now we need to compare each epic to it and decide whether it’s bigger or smaller and put it on the scale. This is what Team Zebra did.
There is no perfect approach, but the conversation output should be a list of epics and to which bucket they belong on the scale.
Don’t worry if you feel a bit nervous; remember, this is an estimation, and we will refine the estimates constantly.
Before we do that, let me summarize what we have achieved.
We now have some data to work with and answer the question of whether we could hit our deadline. We can do that in two ways:
Let’s assume Team Zebra can say approximately how many sprints an epic with 8 points can take. Let’s define this as two sprints.
Then we can do basic math, saying:
Please put it on a timeline.
This is what the Team Zebra estimation looks like, based on our analysis and the condition that our project starts on February 1st.
If we do one more and assume Team Lion also has some similar historical work done and their 34 point is eight sprints, which leaves us with:
Even an untrained eye could see a problem with this effort. So we need to do something. I am sure you know better than me what those items are, but in my experience, conversations go around a few areas:
Let’s imagine the third team is new and can’t put the time factor on the table.
The solution here is simple. Let them work for a sprint or two and then do an estimating exercise and see how many Epic Points they have “burned” for the period.
Let’s say they worked on the new vaccination process for two sprints because this is their main use-case, and now they believe this epic is not a 34-pointer but a 21 now because of their work. So we can now do basic math and repeat the calculation with our data.
As an output of this exercise, you will get a bucket of durations that can give you an initial estimate of whether you could hit a goal. The entire process, of course, is more complex.
It would help if you also thought about the following:
I wanted to have a separate paragraph for this.
One mistake some teams make is to do the estimate once and then forget about it.
At the beginning of a project, we don’t know what we don’t know, but when we know what we didn’t know, we don’t do anything with the knowledge.
Stay away from that trap; review the estimates regularly. Since you work on a perfect granular level – an epic, those estimates will be more precise every time, giving your company a better chance of success with your product. It’s a good investment of your time!
This oversimplified explanation of how to estimate items too early to be evaluated will be helpful to you and your teams. It is a well-structured approach I used many times. It brings transparency and alignment.
Also published here.