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.
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.
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.
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.
The problem starts with the moment the estimation is used for the plan since now everyone estimating needs to be reasonably accurate.
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.
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.
If we need to do the estimate in a better way,
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.
|Estimate is one of following values (read with ‘A Few’)|
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.
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.
|Estimate||Maximum Duration||Range (calendar timeframe)|
|Hours||< 1 Day||0-24 hrs|
|Days||< 1 Week||1-7 days|
|Weeks||< 1 Month||1-4 Weeks|
|Months||< 1 Quarter||1-3 months|
|Quarters||< 1 Year||1-4 Quarters|
|Years||More than a year|
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.
Also, tell me what else you would like to know about remaining agile for scaling teams.