Estimating with Agile
Why do you need to estimate well?
Imagine that you’re a lender; you review loan requests, negotiate the terms and the repayment plan all up front. These are agreed upon and even signed off on by all parties, money exchanges hands, and you bask in the glory of a great plan. Along comes the first payment date and you receive a note from the lendee letting you know that not only is he going to be late but that he’s also going to pay you less money than what you’d agreed upon. What do you do? Well, in this scenario there are consequences that you can enforce and most are painful enough to prevent it from happening entirely. Switch this to a typical internal project and what happens? Are there solid consequences? Finger pointing and blaming?
I proposed moving to Agile in the hopes of eliminating that issue entirely, tired of managing scope creep, exhausted from the politics and wanting a better, less stressful and more harmonious project process. I was attracted to Agile because of the continuous interaction between the teams and stakeholders and the regular assessment of product and progress. The idea that projects could run smoothly and be delivered time and in scope was fascinating, almost utopian.
I was sold with one side comment – ‘And you’ll find eventually that as you deliver on time more often that your relationships with your customer will suddenly get less contentious’
Why do people estimate poorly?
Two words – Ideal Time. How often do you hear the following?
“I’ll be with you in just a moment.”
“Can I steal you for a second?”
“Can I interrupt you for a minute?”
“I can have that to you in five minutes.”
How often is it accurate? How many times has someone stopped by your office, asked you for a few minutes of time only to still be there 15 minutes later? We naturally communicate in lessened demand, we don’t want to seem greedy, and in ideal time, the time we think it would take in a perfect scenario. Perhaps that request for five minutes in the requestors head was the time it would take him to communicate the issue but didn’t include time for questions from you. Or that five minute estimate to return a report didn’t include an unanticipated connectivity issue or an unexpected phone call.
We want to please and we don’t often think in terms of the worst case scenario.
How did we fix that?
Well, in short by breaking down everything into to tasks it takes to get it accomplished, estimating the time for each task and then looking back to assess how well we understood the tasks as well as the time to complete them. Sounds simple right? Well how well do you really understand the unknown? Take a simple request like sending a pivot table in Excel to your boss and jot down the task list:
- Open Excel – <1min
- Get Data – 2min
- Create Pivot Table – 4min
- Save Spreadsheet – 1min
- Attach to an Email – 1min
- Send Email – <1min
Pretty straight forward, yes? But where does the data come from? What version of Excel does your boss use? Will he need help or instructions on how to use it? How large a file is it and how large a file can you email? The answer to these questions could take this simple request from 10 minutes to days.
Not everyone will know the right questions to ask when they begin planning much less understand the time impact of every ‘gotcha’ along the way. By breaking things down to the lowest level, capturing what we missed and what we underestimated, we get better at accurately estimating each time. Our previous scenario might look like this after a few iterations:
- Open Excel – <1min
- Create Data Connection – 2min
- Write Query – 20min
- Test Query – 5min
- Validate Data – 20min
- Populate Spreadsheet – 5min
- Create Pivot Table – 1min
- Format Pivot Table – 5min
- Save Spreadsheet – 1min
- Craft Email Instructions – 30min
- Attach Spreadsheet – 1min
- Send Email – <1min
We went from a 10 minute task to a little over an hour. I don’t know about your boss but if I regularly told him 10min and delivered in an hour he wouldn’t be happy with me BUT if I told him an hour and a half and regularly delivered at that or a little earlier he’d be delighted.
What about Slack?
That brings me to the next piece, understanding your buffer. When I tell folks we always add a buffer to our project I typically get accused of cheating. If it’s in the PMI material it should be a common and well understood practice. Having a buffer merely helps you plan for the unforeseen. What if after telling your boss that it would be an hour, you’re stopped in the hallway for a ‘5 minute’ discussion or pulled into a ‘quick’ meeting. What if twenty other people are writing queries against the same data? What if Outlook restarts on you? None of these things are disasters but if they do happen then you should plan for them.
But I don’t know what tasks I’ll need to do!
You have two options in this scenario – find someone who does or make your best guess.
When I have someone on my team who is working on a project that isn’t something they normally do (say a SharePoint developer is switched to a Reporting Services project), I pair them up with someone who has done it before during our planning meeting. That way the more knowledgeable can assist with asking the right questions, scoping out the tasks and explaining where the challenges might be. I also allow a slightly larger buffer; say 20% vs a 10% default.
If we have to make a guess, my preference is to use relative estimation. Is the project bigger or more complicated than the last project we worked on or is it smaller or simpler? Do I have a similar situation in the past that I can compare it to? Over time we’ve discovered that our velocity is pretty static, we do about the same amount of work every iteration. Using that velocity number I can give an educated guess based upon the results of the relative estimation, how long it will take at an iteration level. I will also occasionally have the team member capture tasks as they go to help us all understand what they had to do and what we may have missed.
If you’re struggling to estimate accurately, my suggestions are:
- Understand the actual work involved – tasking is an easy way to get there.
- Know what your risks are and incorporate a just in case buffer.
- Use relative estimating and your average velocity do derive a best guess.
- Adjust as needed.
A final note to address those in the ‘but my product owners, stakeholder, boss will push back’ camp. There is nothing better than a calendar, with tasks and resources to demonstrate the actual workload and the time it takes to accomplish that workload. I’ve had product owners review a board of tasks and let them ask questions when this has come up, people tend to think they know what it takes and operate from that assumption. Transparency coupled with open dialogue is the key here and over time you’ll find you encounter less push back as you build trust.
Taarradhin 