How a Program Manager Can Estimate Items Too Early To Be Estimated

As a Program Manager, I must facilitate estimates for items too early to be estimated in almost every company I work with.

Why is it needed?

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.

Set the stage

Problem definitions:

• Estimating in a very complex environment is always incorrect. The more prolonged the period, the more significant the error margin is.
• Often somebody else estimates the engineering work based on a gut feeling and the wrong level of granularity.
• 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.

Let’s get practical

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.

How do we do the estimation?

Create the epics

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:

• Build the CI/CD pipeline
• Inject static security scanning in it
• Make sure the pipeline supports all the tests written by the teams
• Enable the release of the software under a feature flag

For Team Lion:

• Registration of new patients
• Closing the accounts and all the related activities of existing patients
• Data encryption to make sure the data in rest and data in motion are protected

Team Cute Dog

• After registering the citizen, this team will ensure they can apply for a vaccination appointment.
• Ensure that the communication with the customer is happening
• And that any reactions to the vaccine or other complaints are correctly handled.

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.

Epic Points

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.

What’s an epic point?

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 expected effort and expertise required to complete the work
• Team’s experience conducting similar epics in the past
• Uncertainties, doubts, and risks at the moment of estimating
• QA (Quality Assurance) tests and bug fixing that might be necessary to complete the epic
• Workflow overheads in the form of communication, meetings, and admin work required to reach completion

What scale are we going to use?

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.

Let’s estimate

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.

Let’s answer the essential question: Are we going to make it?

Before we do that, let me summarize what we have achieved.

• We have a product to build, and all the teams know why we are making it.
• The teams defined their mission based on the product goal
• There is a deadline we must hit because of the upcoming covid season
• The teams with the product owner identified the epics to achieve that goal
• All the epics were estimated using epic points and are now grouped in buckets based on that estimation.
• We have a good and come environment where all this happens.

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:

First: We have some historical data from the teams.

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:

1. In total, we have 71 EP
2. Which gives us around 18 sprints for the team to complete.
3. In “weeks,” this will be 36 weeks, which equals eight months.

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:

1. In total, we have 102 EP
2. Which gives us around 24 sprints
3. In months this is going to be 11 months

How to read the timeline?

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:

• Getting more granularity on the Epics – why all of the epics are 34 pointers – is it because the team needs to learn something, or they didn’t have time to do some proper research?
• Should we cut something off from the original scope that will make us hit the deadline and still give value to the citizen and create a plan to deliver the rest a few weeks after the deadline?

Second: We don’t have any historical data from the team.

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.

• For two sprints, the team burned 13 EP.
• So it means that they most likely will finish their part in 9 sprints, which gives us 18 weeks
• which is ~3.5 months.

Some considerations

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:

• Dependencies – what will happen if team Cute Dog needs to start working after Team Zebra delivers? Then you might have a problem.
• Adding extra work – The team might discover extra work while working on an epic. After this is a fact, you need to assign EP to the new epic and see how this will impact the timeline using the same approach.
• Teams are getting better: After each sprint or two, you should see how much EP the teams burned and do the calculation again.

Teams are getting better.

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!

Final Notes

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.