By Jim Grey (about)
Maybe you’re one of the lucky ones.
Maybe you work in a shop that executes scrum well. Your team keeps the backlog well groomed, understands its velocity, and delivers working software sprint after sprint. Or maybe you work in an open research-and-development shop where the journey is as important as the result, and projects are always open-ended.
If, like me, you have to deliver software on deadline using a less-than-perfectly executed methodology, this post is for you. It’s going to give you a technique for knowing where you stand against your deadlines – a very useful skill that will reduce the chaos you experience and help your boss steer projects more successfully, both of which are good for you.
It is a method for implementing continuous reestimation, which I wrote about in this post. Read it to know why this will make you and your boss more effective.
Teams that have worked for me and have estimated using this technique have seen their projects come in within estimate about 80% of the time. The other 20% of the time, they learned important things about their work that let them estimate more accurately the next time.
Here’s the technique:
- Break down your work into tasks.
- Estimate the tasks using a three-point formula.
- As you work, reestimate every day.
Break down your work into tasks
You might resist this step because in your core you know you will miss some tasks. It’s okay. This process honors that you don’t know what you don’t know. Just outline the tasks as best you can.
But think small, because you’ll be more accurate when you estimate more small things than fewer big things. Break things down as small as you reasonably can.
Estimate the tasks using a three-point formula
For each task, then, think of the following:
- If everything goes right on that task, how long will it take? This is the best case, B.
- If everything goes wrong on that task, how long will it take? This is the worst case, W.
- If a reasonable amount of things go wrong on that task, how long will it take? This is the likely case, L.
Think for a minute or two about each task, but any more than that is probably overthinking it.
Important: Calculate your estimates in hours. Not days, not weeks, hours. There’s too much slush in days and weeks. Besides, in an 8-hour day you probably work just 6 hours on project tasks. You spend the other two hours in meetings, having hallway conversations, using the restroom, and being interrupted.
Here is where some magic comes in. Just go with me on this. For each task, drop B, W, and L into this formula and calculate the answer.
You’re weighting the likely case, but honoring the best and worst cases – and in one deft motion you take fear out of your estimates. What makes estimates bad is either unexpected things happening or overpadding for unexpected things happening. Thinking best/likely/worst helps you be more objective. And when you add up these three-point estimates for all your tasks, you get a reasonable cushion for the things that could go wrong.
Divide the number of hours by the number of hours per day or week you will work on the project. Lay that number of days out on a calendar; tell your boss that’s when you’ll be done.
As you work, reestimate every day
You are going to discover tasks you didn’t think of at first. And some tasks are going to take longer than you originally thought. When this happens, estimate the new tasks and/or reestimate the task that’s taking longer. Recalculate your end date and break the news to your boss.
Your boss ought to kiss you right then and there, by the way, because you gave him or her information early enough to do something about it – adjust scope, add resources, move the date, or tell you that unfortunately you are looking at some late nights. Hopefully the answer will be a, b, or c more often than d.
And every time you have to reestimate, you’ve learned something about your work that helps you estimate more accurately in the future.
Jim Grey 