I have been building software products for a few decades. Still, getting to meaningful estimates is sometimes challenging since there are so many unknowns.

The unknowns increase with agile since you have not thoroughly thought of the requirements or performed detailed analysis. Because of this, several agile estimation techniques have become popular, like T-Shirt sizing where you are choosing something abstract instead of absolute numbers.

This blog focuses on finding a better way to estimate size.

Why estimate?

Ideally, estimation should be optional in an agile environment since consistency in delivering value is most important (State of flow). There are movements around no-estimate that promote the same.

However, there are a few reasons why you need at least a rough estimate.

• Know if an item (MBI/Epic/Story etc.) is worthy of getting into the backlog. Even the no-estimates method wants everything to be small.
• Once in the backlog, you can prioritize items. An estimate may influence what you do first.
• For planning (in my opinion, it is best to limit or avoid planning in an agile environment and I will cover this in a different blog), Some teams want to use it for resource planning. And some product teams end up making release commitments based on the estimates.

The estimate has been a sore point with agile since there is less importance on the duration in agile. Hence teams keep going back to old complex ways of doing estimates to make commitments.

Predictability with estimates

The root of the problem starts with predictability. Stakeholders want to know “what will be delivered when?“.

Let’s see how teams answer “What will be delivered when?” by focusing on estimations.

• Prioritize everything in the backlog.
• Estimate every item in the backlog. Although, with keeping unknowns in mind, the estimate has to be abstract. It now needs to be more accurate.
• I have seen various product teams estimate using paradigms such as T-Shirt sizing and the Fibonacci series. But this is not sufficient for doing commitments. Hence there is hidden time commitment inside these estimates. For example, let’s look at Agile Estimation with T-Shirt Sizes

• From the above table, it is clear that one starts with a Small/Medium kind of estimate. But to make sense out of it, they put another duration and effort angle on it. So at the minimum, you need a table such as above to make estimations usable at this stage.
• However, When you go in resource planning and release planning, the above is often also not enough, and typically, it follows an old-style detailed estimation exercise.

The problem starts with the moment the estimation is used for the plan since now everyone estimating needs to be reasonably accurate.

Complications of estimates

Buffer in everything:

While committing, it is reasonable to have a buffer, but with the current model, you have a buffer in every single item. And some individuals may estimate with a lot of buffers and some with less. But you do not get a realistic idea about the duration. Worst once you have a padded duration, you will take up all the time to finish the task as per the Parkinson’s law.

Consistency:

If you consider an abstract estimate, will two people produce a similar estimate? Well, many teams use relative estimates to overcome this problem.

Now looking at the T-Shirt sizing kind of estimate, how do you ascertain a large item’s definition? Understanding these comparable items can be difficult when a new team member joins a software development team. It is also difficult for large product teams to prioritize (based on estimates) many things across multiple teams for the same reasons.

If you tell an outsider that a particular story is large, what does it mean to them? They can’t make sense of it unless you map them to duration that they understand, as shown in the T-shirt sizing table above.

Effort (to estimate):

More detailed the estimate, more time it takes to do it. In my personal experience, I have seen teams doing traditional MS Project style planning with resource allocations to increase the accuracy of estimations. Ideally, estimation should be reasonably quick.

Difficult to understand:

Usually, you don’t know how to interpret someone else’s abstract estimate called Small, Medium or Large.

If you want to do a more accurate estimate, you will need to put more effort, and there is the risk of buffering.

If you want to do a relative estimation or abstract estimates, they will not be consistent or difficult to be understood by everyone.

The ideal technique for estimation

If we need to do the estimate in a better way,

• It should be easy to understand. Everyone must easily relate to it.
• It should be reasonably consistent across different teams or even cross-functional teams. An outside member should be able to make sense of the estimate.
• It should be quick to estimate.
• Estimations should not be directly linked to commitments to avoid buffering, although it should help in doing them when required.

What if we wrote the estimate in simple terms like the item will take a few hours, a few days, or a few quarters without adding any number to it?

If I need to estimate Story A, My estimate will be “a few days”.

It dramatically simplifies the estimate. It is fast and easy to do. Everyone will derive the same meaning from it.

So ideally, an estimation can be done with a rough person duration (man-hours/man-days as we know it) without an absolute number.

There is one more aspect to this, how does one determine what this estimate represents? Does it include the entire SDLC or only specific portions? I recommend limiting it to pure coding estimates (or to something that everyone connects to in your team).

I have found programmers invariably just thinking about code when asked for an estimate; it comes naturally. However, if you ask them to think of SDLC, you will have a significant buffer added to it since they don’t even control the entire lifecycle.

The Few-Duration technique

1. We select from the following values for our estimate Hours, Days, Weeks, Months, Quarters, Years (You can read it with ‘a few’, i.e. a few days or a few months).

2. No other number is associate with it. We don’t want to estimate that it will take 5 hours or two days etc. That will break the benefits of this model, and we are back to where we started i.e. pure person duration estimates.

3. And it represents core development effort only. (or whatever you agree and is consistent across the organization, but the development only effort works the best).

As you can see, this is pretty quick to estimate, easy to understand for anyone, consistent even for a brand new member in the team, not linked to commitment directly but can help in it.

There is some more detail hidden around this estimation technique. Something that is a few hours is less than the next category of a few days. Hence you expect that the coding work for that will finish in less than a day.

The range each estimate value represent.

While talking to one of my friends about this, he mentioned that he is unsure if these are business hours or elapsed hours. I said “A few Hours” are always less than a day; so it could be a business day or elapsed day. Hence, if something is going to take 24 business hours, I will put that estimate as Days rather than Hours. The notion here is that when someone says “A few Hours,”; they estimate that they can complete the coding in less than a day. Similarly, if the estimate is “A few Days”, they will complete it in less than a week.

I like to call it the “The Few-Duration” estimation technique.

You can make reasonable predictions with (the few-duration) technique, e.g. if you have started to work on something that takes a few hours or a few day then there are high chances that the team will finish it in 2 weeks sprint.

I still haven’t covered how this technique is useful when doing resource planning or release planning. I promise to cover that in my next blog, “The Art of making commitments at scale”. Subscribe to get notified when it is available.

I am looking for feedback on this technique. Please hit the comments below with your thoughts.

• Do you agree/disagree with the thought process here?
• Will you embrace it?
• Do you have a better name for the technique?

Also, tell me what else you would like to know about remaining agile for scaling teams.