Still Puzzled about Estimation?

While working with clients, I’ve seen so many different challenges with estimation – very similar challenges across industrials and across culture.

While collaborating with various clients, I’ve seen a multitude of challenges associated with estimation, experienced by almost everybody – namely, ScrumMasters, Product Owners, project managers, agile delivery leads, managers at different levels and of course, developers. And interestingly, these challenges transcend industries and cultures (as of today, I have had the privilege serving individuals and corporate clients from 80 countries).

Let’s delve into the topic of estimation, which has been a chronical headache for many. I aim to share some tips to help first reduce and hopefully eliminate the headache for good at some points.

First, let’s establish some alignment.

Why do we estimate?

Estimation serves the purpose of gaining a rough understanding of the amount of work. This information may aid in prioritization, planning, and navigating uncertainties and potential risks.

How do we perceive estimation?

In our foundational Scrum workshops, we start to build the right understanding about Agile but discussing Agile Lenses. Through these lenses, we view estimation as an activity that should be ideally minimized, with the ultimate goal of entire elimination – termed as a Non-Value Added activity in Lean methodology.

Having clarified the purpose and ideal perception of estimation, let’s shift our thinking.

Often, we find ourselves attempting to predict the future, investing time and energy in discussions to agree on an accurate number of hours or days. However, this tedious effort always turns out to be inaccurate, leading to a situation of “being accurately wrong” at a considerable cost. Many people put much time into this predication work. Instead of striving for accuracy, imagine I we shift our thinking to just being good enough, just to be approximate right…

Absolute numbers tend to spark intense debates, while comparative discussions often lead to quicker consent and even consensus. In situations where estimation is deemed to be truly necessary, start to use relative comparison if not yet.

What do we estimate about?

Before we dive into this alignment, let’s start with a relatively relaxing scenario – building Lego houses.

If I ask, “How long would it take for you to build this Lego house?”

I am confident that your answer, my answer, and the next door senior grandparents’ answer would differ.

If I ask, “How difficult is it for you to build this Lego house?”

As you can imagine, the answers can vary again among you, me and the next door senior grandparents’ answer, because we all have different level of competence, and our speed in building can vary rather significantly.

Now, let’s introduce a second photo of a Lego house and let’s look at the same set of questions.

“How long would it take for you to build this Lego house?”

“How difficult is it for you to build this Lego house?”

The answers can vary once again.

And we can sit here, discuss, discuss and discuss…

We will most likely still disagree with each other, and even somehow we managed to reach agreements – that’s because we are tired of this discussion?

Now let’s experiment with a different question.

“What’s the relationship in terms of the total work required between building these two houses?”

Let me first share my thoughts with you, and see whether you and the seniors next door would agree. “I feel that the smaller house entails much less work, and roughly, approximately, the larger house possibly leads to 3 times more work compared to the smaller one.”

I’ve tested this concept in my public CSM workshops, where participants have concurred. I actually even checked with my 84-year old mom, and she also agreed, yes, it is about right, and she also named a few key elements she considered, such as the green ground, house size, roof, and other extras.

Translating this to a product development context, factors like the green ground, roof, house size would correspond to considerations about the front end, different layers, back end, integration and some possible extras.

Therefore, when Scrum Teams size works for features and/or usr stories, developers can relatively compare to gauge the required effort. It’s not about how long or how difficult it is for a developer, as these can vary greatly. By focusing on relative work comparisons, we remove our differences in competence and speed, and even differences in our personalities (do you have colleagues who are always ambitious and always give very optimistic answers? I am sure you also have friends who are always conservative and put buffers?)

So to summarize before we go further.

• Estimation is a Non-Value Added activity which ideally should be minimised and eventually eliminated;
• Relative comparison helps focus on Value Added activities, so that we can arrive at “approximately right” with minimal amount of time and energy;
• When we work relative comparison, we evaluate the amount of work involved to build the feature;

Now let’s take a look at some further practices that can be facilitating the process of estimation, if you have to do it.

We love visualization!

Support your developers with one of the options below can be helpful.

(1) Visualise past sprint data.

Give your developers opportunities to compare with something they just worked with. Memory is still fresh for all developers.

Imagine if one developer comments,

“This new user story is very similar to the 2nd user story we worked with last sprint.”

 

(2) Visualise past data in terms of user stories recently completed and their respective sizes.

Now imagine again…

During your product backlog refinement, while looking at a new user story, one developer comments now,

“Oh, this new user story is very similar to the XYZ user story which is at 5 points.”

 

(3) Multiple teams – many user stories

You might be working with multiple teams while you are developing a single product. If you are curious about scaling, you can check out our scaling skills program.

Would like to share how we worked with dynamic estimation back in 2011.

Back then, I was working with coaching multiple teams working on a large legacy telecom product. The teams were working with T38 Fax Over IP feature. If you are interested in knowing more about the technical aspect of things, here is an overview.

Development work used to be done via competence areas and subsystems. To introduce a new feature, we would have to work on many of the subsystems and components. So… a lot of competence challenges as now we started to work with feature based, instead of component or subsystem based approach like waterfall days.

As we had multiple teams, we were also refining quite some user stories. We experimented dynamic estimation for the very first time, and it was a huge success.

A helicopter recap of the steps were:

Developers started to read user stories which were printed on A4 paper.

The 1st developer who was ready put their user story on the conference table, based on their sizing of the user story.

The 2nd developer put their user story on the conference table as well, positioning it based on their sizing decision (to the left or right, if it was bigger or smaller).

At any time, developers would take turns. A developer could either position a user story, or move an already positioned user story, by sharing briefly their key messages in one or two sentences.

Once over 80 user stories were positioned, developers started to cluster user stories at similar size together, and gave it a story point. The entire process lasted about 90 minutes, and developers from multiple teams sized over 80 user stories (86 in total if my memory serves me right).

Hope the above tips help reduce your headaches about estimation, and hopefully one day you can eliminate that headache entirely. Remember, estimation after all is a Non-Value Added activity.

Similar logics apply as well for roadmap planning, release planning, stakeholder management etc.

Finally, don’t forget to join our global community of agile practitioners – we have practitioners from 81 countries in our community, across different industrials and a lot of diversities.

Join our upcoming programs, and/or subscribe to our newsletters.

Join our global community for latest updates and network opportunities!