Estimation Is Not For Accountability (It’s For Visibility)
Filed Under Estimation, Software Process
Almost all software teams run some sort of software process whether it’s Scrum, Agile, Waterfall, or Scumerfall. Each and every one of these processes includes a window of time (for example, Scrum uses the concepts of 1 week iterations).
A recent comment made me about fall out of my chair. Paraphrasing:
One of the best reasons [from a management perspective] to adopt Scrum is the fact that iterations are “accountable commitments” to what the team could accomplish in a week…
Screeeech. No. Estimations are not meant to be used as accountability rulers. They are meant for visibility.
But don’t we need estimations so that we can make business decisions and commitments; therefor aren’t they for accountability? Although, the last sentence would suggest a maybe…still a resounding – no.
Let me make something perfectly clear to everyone reading – nobody should ever be held accountable for estimations. Estimations are naturally shitty, wrong, and optimistic, so why even continue to do them? Because we need the business visibility of how long software is going to take, and as a measurement stick if we can continue the current game plan or react to a different (less optimistic) reality.
I want to repeat that – it gives early visibility to know that our business schedules will work, or early warning they will not so we can react accordingly.
So you are a team manager a few weeks away from a deadline that appears is not going to be meet. What are you to do? Here are a few things to avoid:
- Ignore the early warning signs and pray for a miracle
- Guilt or force your team into working overtime
- Don’t start preparing upper-management that timelines may slip
- Post Deadline: Chew out your team for not making the deadline
Alright, what should you do? Here are a few ideas:
- Realign management strategy
- Bribe the team into working late with food, bonuses, or tech gizmos
- Post Deadline: Aid your team in providing better estimations
Being middle management should be one of the hardest jobs. I have equated software management to being an Army Sergeant, and how you handle the tough decisions of this scenario really draw parallel. You don’t push hard against the officers – shit rolls down hill onto your troops. You don’t rally the troops to accomplish the mission – the overall strategy goes to hell. Either way, you are not a popular person but that is because you make all the hard decisions that everyone else skirts around.
22 Responses to “Estimation Is Not For Accountability (It’s For Visibility)”
I like the practice of breaking out unknowns into spikes to go do before you even estimate on something that your unsure of
s/hear/here/
[…] Estimation Is Not For Accountability (It’s For Visibility) (Max Pool) […]
[…] Estimation Is Not For Accountability (It’s For Visibility) (Max Pool) […]
@Scott –
Even when developers understand how to solve the problem, they don’t understand how deep the rabbit hole is.
@Ruben –
Thanks, fixed.
as a middle management man, you need to make a compromise on the estimations your team gives on every task – the much you break tasks into smaller pieces the easier to estimate.
some people need to make them feel guilty if they don’t do what they committed to.
you need to push them toward finishing their tasks – being accountable.
I think what make someone go to work every morning and work 10 hours a day is commitment to feed his/her family – being accountable – and on the same stage being accountable of what estimation you give should be a good reason for working hard.
so, ask your team to estimate, guide them, give extra time in the initial estimation, and don’t be much optimistic – if you do this you (and your team) are in safe place of upper management shots 🙂
@Osama –
If you have to push your people to finish their work, you might have hired the wrong people. If you don’t believe that then you are pushing them into an unrealistic deadline (which you think is possible).
Either way, estimations are not to be compromised on. If anything, they should be taken at face value and tripled.
if it’s your choice to choose your team members that would be happy life! and sadly that is unusual due to many reasons.
pushing people might mean encouraging and supporting them.
also, I think being a realistic is something determined by the context of work, the expertise you have at hand. and that is why a middle management man should push people and support them estimating tasks.
You are 100% correct and I agree. Most dev teams would agree but most customers would dissagree. The hard part is explaining this to customers and getting their buy in about estimates. I feel that is the talent that is holding back successful development projects.
http://www.leadingsoftwaredevelopment.com/2008/11/why-is-success-measured-by-estimates.html
@Max
reading extrememprogramming.org they talk about how architecture should be considered spikes even and they can last over iterations.
@Osama
I find asking people to meet an impossible deadline is demoralizing. if its a hard deadline its motivating.
First, Love your blog.
Second, I totally agree that estimations are always shitty… they’re estimations, which by definition are “best guesses based on current information”. I also agree that estimations are for management visibility. Our team makes commitments to ourselves. We commit to getting these STORIES done my the end of the iteration.
The estimations are good gauges of whether I’m getting caught in a rabbit hole. But developers should never be afraid to adjust an estimate (for mgmt visibility, of course).
great post.
~Lee
While true that estimations for the product backlog should not be used to hold developers to timelines. When you break the product backlog down into a sprint. There should be a reasonable expectation of what will be completed after the sprint. To quote Mike Cohn:
” the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration. […] The purpose is to figure out how many and which product backlog items they can commit to delivering in the coming iteration.”
Also, you need to make sure you’re providing data that will let other departments and management know if the commitment isn’t being met. (through task breakdowns and hour estimations or some other means) It’s difficult to reset expectations if no one except the developers know the deadline is slipping.
[…] via [codesqeez] […]
if a task is going to take 2 days to complete, it will take 2 days, no matter what is your estimate.
breaking your work to smaller tasks and considering unknowns makes an estimate close to what a task will take to complete.
“nobody should ever be held accountable for estimations”
I hope your key word there is SHOULD. The unfortunate reality is that in real life we ALL are held accountable to our estimates every day – all the way from “What time will you be home, honey?”, or “how long will it take you to clean the garage?”, to “how long will that meeting last?”
Projects need planning. Remember the old adage – “Failing to Plan is the same as Planning to Fail”. How can we adequately plan without estimating the amount of work that it takes to do something? Those signing the paychecks need to have these estimates so they can plan their business, budgets, and other initiatives. Therefore, estimating is something that MUST be done, and because of the importance of the outcomes – should be as accurate as possible.
Most of all – our estimates set expectations. The biggest cause of failure is the unmet expectation. During estimation, caveats must be set, assumptions documented, and customers and users of those estimation need to be painfully made aware that “things” happen during the development process. Hence, the need to be assertive about setting expectations, communication, and adjusting of scope when necessary.
Bottom line – we are all held accountable to our estimates, but by communicating and setting the expectations correctly we can help the planning process continue smoothly.
@Paul –
Winston Churchill once said “Plans are worthless, planning is priceless.”
Estimations are part of planning, so to that point I agree they are a necessary evil. It is when that planning to took literally into inflexible expectations and plans that they doomed for failure.
There are 2 levels of accountability we should be discussing in regards to Scrum Development.
#1 CoWorker Accountability
The unit of 1 week in the Scrum process is advantageous as this is something with a reasonable amount of granularity.”Accountable Commitments” can also mean under the context of being held accountable and making commitments to *each other* and not necessarily to upper management. I wholeheartedly agree that a Scrum Dev Process benefits greatly from co-worker to co-worker commitment. That underlying promise to do our individual best to get X unit of work done this week. This is a much more personal level of social connection within the workplace and accountability from the fact that not accomplishing your goal simply means you let the group down and didn’t do your part. Again this wasn’t meant to imply accountability to steak holders necessarily.
#2 Stakeholder Accountability
“Nobody should ever be held accountable for estimations” -uhm what? That’s a huge load of crap. Who in the world would want to work with someone that said “Hey this project will take 1 week…buuuut don’t hold me accountable for it”. Of course estimations change through time and are very organic in nature as the boundaries of the project and requirements change through the dev process. But to blatantly say nobody should be held accountable is a huge load of crap. I’m calling BS here, you totally just dropped that to get some flame action!
@Justin –
The great Steve McConnell once said, “estimations should be good enough to be within 25% correctness, 75% of the time”.
Don’t assume I am removing all accountability for false or wild guesstimates, but I am suggesting that holding people to estimates as measurable actions and timelines is a mistake.
After all, would you want to be held responsible on timelines that where only accurate within 25% 75% of the time? Do not take estimates as commitments is the moral here, not remove all instances of accountability.
Hmm If Steve’s so great, why haven’t I heard of him mmm ? 25/75 leaves quite a bit of margin btw. Kinda sounds lazy if you ask me 😉
There are many many instances where estimates SHOULD be taken as commitments. It connects the person making the estimation with accountability which reinforces the whole refinement process each of us go through as we develop. Incorrect estimations with absolutely no consequence certainly doesn’t bode for a higher degree of accuracy over time. Is Bob going to give better estimations cause he’s a good guy? Hell no..he’s giving better estimations because if it doesn’t they’re gonna boot his @$$.
@Justin –
Steve McConnell is like Jesus, and I would definitely run out and buy the bibles Code Complete and Software Estimation, Demystifying the Black Art
@Max
Like Jesus as in completely fictional or Jesus as in generally a likable guy?
@Justin –
As in just go read the f’in book. 😉