Skip to content

Demystifying Agile: Rants of a Madman – Estimating Efforts

April 30, 2012

How many times have you been asked to estimate the size, scope, cost of a project?  How many times have you had to set expectations to secure funding and resources in order to start a project?  How many times have you been asked if you are going to make your delivery commitments or not?  As a Software Development manager it feels like almost every hour of every day, right? ;O)

As managers of Agile efforts I would recommend that we should not make the same mistakes that many bottoms-up oriented managers and project managers made and often continue to make under waterfall.  You always have two ways to approach estimating projects: 1) bottoms-up; 2) top-down. I would contend that bottoms-up never works, has never worked, will never work. Just my own experience.

How many project teams have you seen try to take their MS project Gantt charts with resource loading, total up every amount of time Bob and Sally have allocated, and then produce a magical date, budget $, or useful resource utilization map? How many times have you seen the team be even remotely correct? I’ll contend they were wrong before even hitting the print button let alone a few weeks or a month or two down the road.

So riddle me this?  Why would anybody think totaling up all the story points bottoms-up in an Agile team will yield better results? I strongly believe that Agile provides some of the best visibility in to useful metrics for trending and helping to arm managers with enough data to land the plane close to target (In Part 2 of my Elevator Speech Series “On Time” I talk about how Agile gives you visibility in to what is going on within a project like no other methodology).  That said, I don’t think there’s a formula to get to the answer in a bottoms-up only way.

Just like how your project plans were not worth the plotter paper consumed to figure this out, trying to roll #s up in a bottoms-up approach from your stories will yield similar results. Why?  Because you don’t know what you don’t know. There are stories that have yet to be written. There are story points yet to be assigned. Oh, yah, and story points don’t translate in to any meaningful unit of time known to a mere mortal and they differ by each and every team (okay that was my other rant).  I’m glad you can show me your velocity and burn down charts, but not all of your stories in your backlog are written let alone estimated now are they?  Be honest…  Just like all of your tasks in your legacy MS project plans had placeholders for estimates vs. real estimates, huh?

Top-down estimating by someone who is experienced, backed with meaningful examples and data vs. being a guess, is the only technique that I’ve ever seen actually work. That is to say, how big is this effort? How complex? What projects have we had in the past that are similar in scope, nature, complexity? How long did those take? What makes us think this will take any shorter? Any longer? Is there any bottoms-up data to date for the effort (and trends) that may prove useful to factor in as a sanity check for an estimate?

The good news is with Agile we actually have better visibility, data, and a wonderful cadence to help base these types of estimates on.  How many sprints should this take?  How many more sprints should we have left? Any hardening sprints? Any remaining buffer sprints for handling one or two lightning strikes (i.e. teams are always surprised by something–leave room for a couple)?  What has our velocity been and do we believe we’ll maintain similar rates?

When an architect provides an estimate for how much a house will cost to build do they count every nail they think will go in to the structure or do they base an estimate on similar homes that have been built from their plans before for other clients? The bottoms-up data can help, but never does a formula yield an answer.  The same holds true for both waterfall and Agile projects.

Scrum Masters and Managers, to be promoted up through the management ranks you have to get comfortable doing estimates and then being fairly accurate in what you project.  No detailed analysis of bottoms-up data and fancy silver bullet formula will ever hand you an answer nor will it help this promotion path.  There is no magic formula or trend line to whip out that will answer the question for you—if there was everybody would be promoted up through the ranks. You only get this way through experience and practice.

In my prior lives those who keep trying to answer estimating questions bottoms-up ended up frustrating their customers, were almost always wrong, and didn’t know how to mentor other managers on how to best size / estimate efforts effectively.  Worse case they couldn’t call Bovine Scat when a ridiculous estimate was shared and were the victims when their teams ended up being way off the mark.  Those who could master answering estimating questions top-down, while leveraging relevant data and trends, were the true masters who grew in their careers:  remember that at the end of the day the business customer really only cares that you are delivering high quality solutions on time and budget which delight customers.

Those managers who tell others “I cannot tell you what the estimate is until all the stories are in and all the story points are estimated so I can roll up the numbers” are not long for this Agile Earth.  Same held true in the past for those managers who told others “I cannot give you an estimate until I develop a complete MS project plan with full resource loading” back in the day…

So, let’s help your resume and your career…  Let’s start exercising that part of the brain that lands on realistic top-down project estimates vs. suffering analysis paralysis when you only look at bottoms-up data.  You’ll make mistakes, you’ll learn from them, you’ll learn from others, and you’ll grow.

This is all just one man’s opinion after doing this enough years to be dangerous though…  Yours?

About this series:  I love Agile; I also hate Agile.  I love how it can free teams to truly delight customers while delivering high quality products on time.  I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size.  My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.

Advertisements

From → Agile, Software

2 Comments
  1. Anthony L. Testi permalink

    Estimates are Estimates and need to be revised on a on going bases. Estimates should be given with a confidence level and a high and low estimated. e.g. at the start of the project I estimate it will take 100 to 180 hours of billable work with a 75% confidence. After 20 hours of work I may now say it will take a total of 110 to 150 hours with a 85% confidence. etc. At the start the numbers are best guesses as time passes the become more ‘real’

  2. Hi Mark–

    “So riddle me this? Why would anybody think totaling up all the story points bottoms-up in an Agile team will yield better results? I strongly believe that Agile provides some of the best visibility in to useful metrics for trending and helping to arm managers with enough data to land the plane close to target”

    Two things;

    1. You’re technically right– adding up the story points alone isn’t effective. But in the same paragraph you highlight how an effective and experienced agile “team” SHOULD estimate. In my experience you’ve introduced an artificial dichotomy– top-down/bottoms-up– that agile works to minimize. The Product Owner, Scum Master, and Scrum team members should ALL be using the tools in the toolbox to plan their sprints. None of it should be done in a vacuum or in isolation– the whole team should understand their velocity and burn-down, etc, which of course informs their estimates when putting together their sprints. So back to your original point– top/bottom, there shouldn’t be any such thing– planning sprints should be a “team” activity using a variety of inputs.

    2. Why even talk about waterfall? The inherent flaw in waterfall is the assumption that you can plan out the entirety of a complex project from the start. I have NEVER seen that work correctly without major changes along the way. Those changes them become a variation from “the plan” and the cycle of trade-offs begins–scope, schedule, budget– GAACK! What do we do?! If they were seen as the inevitable outcome of trying to completely plan a complex delivery, then it wouldn’t be a problem…but alas that ain’t how it works. And to Anthony’s point above– estimates are seldom taken in the proper context; estimates are estimates until they become actual time. The further away you are from “done” (in any methodology), the less reliable they are.

    In the end, I would disagree with your premise (while simultaneously agreeing with much of what you said…) Effective estimation is the result of a competent “team” who knows their capabilities, knows their backlog, and who come together to push, pull and prod each other in an open dialogue to plan their sprints accordingly. Simultaneously they adjusting and improving constantly. It is not a top-down one person show.

    Regarding whose career should be advanced; You are absolutely right in saying, “…at the end of the day the business customer really only cares that you are delivering high quality solutions on time and budget which delight customers.” And if you are a capable leader who can build a competent team (that also estimates well…) to do that, then THAT should be the career builder. NOT for being the hero who does it all themselves.

    Thanks for the post. I always enjoy your mad ravings!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: