Just my 0.02 units of currency - but :
Don't confuse estimation with setting a final project delivery date
Consider estimates as an input into a process, not an outcome/performance
Estimates can help the team plan their work and spot bottle necks/problems before they happen
Estimates can confirm and communicate a shared understanding
Velocity could be the answer - I'm not sure
Don't use estimates to measure output
Trust the team is working hard and the stakeholder isn't out to get you
Yup. But it does look like it's going on all night. The debate still rages, and who doesn't love a heated debate. https://twitter.com/search?q=%23NoEstimates
There are very smart people advocating for no estimates at all. There is a nice post by Malcom Isaacs, called "The #NoEstimate debate", which seems to hit a lot of the high notes and key players.
As I have come to understand it, the origin of this debate was trigged by a 2012 blog post titled No Estimate Programming Series by Woody Zuill, where he outlined the case for #NoEstimates.
No point me rehashing the debate, it's better if you read the debate summary and origin post above. Then I can dive into my own 0.02 units of currency on the topic.
Why am I sharing? Because I want to test my hypnosis. By sharing my thoughts and take on this, I am actively seeking contrary/other/agreeing points of view, so I can be better informed and make the right choices for my self and my team.
Some criticism of estimation, to me, seem to be linked to other processes people associate with estimation.
Using estimate to set hard delivery deadlines at the start of a project is very unpopular (rightly). Estimation is being associated with that bad practice, but it's not the process of estimation at fault - its how the estimate is being used.
Waterfall vs Scrum vs Kanban vs ?? It is another debate entirely, while making estimates can be a critical component of wider project management frameworks, I think its important we look at estimates on their own merits (or failures) and not taint estimation with our feeling of related (and/or dependent) processes.
I consider an estimates to be part of the input, not the output.
Accelerate Metrics have give us fantastic ways to measure software development teams performance/Code Metrics, backed by some impressive research. They measure outcomes and there are a bunch of tools to help make this easy. None of the accelerate metrics, measure input, the book does talk a lot about the inputs - but they don't measure them.
If you start using inputs, as a measure of outcomes, you can get into an ugly place, fast. It sets up (and rewards) all sorts of bad behaviour, like padding estimates and/or you see Parkinson's Law kick in.
I admit, the idea of not doing an estimate is appealing.
Its less work, one less thing to do, before we get to the fun part of creating. It is easy to revert to #NoEstimate in times of stress or urgency - we don't have time, it doesn't add value, just get it done. Right?
But. From the Original Post that started it all:
Ask Boss to select one “small” thing that she felt was very important.
Quite a bit to unpack here:
So now we are talking about degrees of estimation, not #NoEstimation. Right?
How does the team/pm/dev know what "small" is? Relative to other tasks? Relative to total time of the project?
Why pick a small thing? Why not just the very important thing?
Even in #NoEstimate, we still expect estimates.
Even if you remove the word "Small" and used any story without some kind of understanding of size, then there is the question of what's the right size for a story? How do you know when to break a story down more or leave it alone? What becomes our unit of work?
So we do estimate, the question is more about WHAT we do with the estimates.
If we do have estimates (and we do), what should they be used for? I would argue, as in input, they should be used to make sure the team members are OK.
Is the team member stuck on their current task?
Does the team/team member have too much work?
Does the team/team member have enough work to be happy/busy?
It's hard to answer the above, without some metric or measure of input.
Looks like Mike has been on the same task for a week - is that OK?
Task was expected to be completed quickly = No, he may need help. We also may need to re-assess similar work in the future, what did we miss?
Task was expected to take a whole = OK, keep going, don't interrupt.
5 tasks, no estimates, is that enough work for Jane for the next 2 weeks?
All tasks are small, expected to be completed quickly = Probably not, may need more - by why does she only have small tasks?
A mix of small/large = Yes, probably
All tasks are huge and complex = More than enough, perhaps we need to see about sharing out the work better?
If we use estimates as a way to keep teams happy and productive (not as a measure of output/outcomes), I think we can keep a lot of the value from estimation, its when estimates are used as a tool to measure output and/or fix deadlines, that we get into trouble.
"It depends" → "It doesn't matter"
But then why bother at all?
Because, I would argue, the value is in coming from an agreed group understanding on complexity/likely time to deliver. Doesn't really matter how you measure it: hours, story points or story count - it doesn't matter. The value here is in (as a team) exploring and communicating what needs to be done and how hard it might be to do it, before you start doing it.
The process of estimation is high value. Estimating work means dedicating time to understand it, agreeing on that understanding and then communicating that understanding in a standardized way.
That act of discussing, and then estimating can tease out unexpected or overlooked complexity, miss-understandings and gaps in understanding. If 3 devs agree, but one other has a very different estimate, that is something to be discussed.
Small? I've found that once a single task gets over a few days, all bets are off, so we should break it down and/or get more context. For me, an upper bound on tickets should be a few days.
What metric you use is much less important than the act of discussing and agreeing. And, once you have that agreement, that metric can be communicated to others, who can take it into consideration when deciding on the importance of any give task or group of tasks to achieve an outcome.
Precise estimates and other logical fallacies.
Another key criticism of estimates is they are not accurate, and so they are not worth the time. As I discussed above, I don't think this is true. The value is in the process, as much as the output. Refining the accuracy of the estimates is useful in as much as it helps the team communicate and coordinate and better manage their own time/and input, not output.
They get even less precise if they are used as a measure of output, as they are easy to game, pad or otherwise manipulate.
In many #NoEstimate posts, they point to looking at velocity (tasks/stories completed) as an alternative to estimating.
Velocity is not without its drawbacks, it can be manipulated and may incentivize the wrong behaviour depending on how the metric is used.
But, even if you skip estimation and use velocity, you are still actually estimating on the front, to slice up the work into "small" story units to work on. But you lose resolution, A 1 line type-o fix in a field label vs adding a new database abstraction layer - both could be a single story, but with very different estimates and are not equal.
It feels like trying to measure an input, with an outcome. And you are going to miss out on the other benefits of estimation, if you skip the process. But perhaps its fine - I'm not sure.
The final key criticism of estimates I want to consider, is fear. Fear that the estimate they create, will be used as a tool to punish or pressure them to do things that are unsustainable, unreasonable or unachievable and which then cause undue stress and disappointment.
Yes. This can (and does) happen. It shouldn't, but it does. Will abandoning estimations fix this? I don't think so. It might move the conversation from quantitative, to qualitative - which may buy time or give the louder voices a chance to control the narrative a bit. But, if the manager/business/client etc already doesn't trust a team, a number (or lack of one) isn't going to change that.
