Estimating versus Timeboxing, part 1
4 comments Latest by Robby Russell Thu, 11 Jun 2009 19:16:34 GMT
As if delivering projects wasn’t hard enough. Delivering projects on time is even harder. As practitioners, we’re all responsible for measuring up the obstacles in front of us and are accountable to those measurements. At least, we should be.
One of those measurements is time. Time is a funny thing. People have a lot of interesting things to say about time. Some say that it’s one of the most valuable things that we have… but I’ll avoid diving into a philosophical discussion for now.
What I wanted to talk about was project estimation. Specifically, estimates for deliverables. For the past several years, our team has put a lot of effort into becoming more accurate in our time estimating skills. Despite analyzing how often we over and/or underestimate the time each of us believes it’ll take to complete a task, we find ourselves coming back to the drawing board.
A few things that we’ve learned.
- Tasks that we believe will take a few days/week/more to complete are often underestimated
- Tasks that we believe will take less than a few hours are often more accurate or overestimated
- Too many tasks were completed with a bigger budget than was necessary (lower ROI)
- A lot of time was spent working on requirements refining to get better estimates
When we began to step back from this and look for patterns, we found that several of the tasks that we would budget hours for (versus estimate hours for) were proving to be more accurate. This approach is most commonly known as timeboxing. With timeboxing, we can place a dollar value on a specific task and work within that constraint. For example, with our clients, both parties can come to the conclusion that, “we believe that it’s worth up to $800 to implement this new functionality.” With that, we’re able take that dollar amount and figure out how many hours to box ourselves within.
The underlying question to our client with each change/feature request is, “How valuable is this to your business at this point in time?” Whereas, with a typical approach to time estimates, a client comes to you with a list of changes/features and you provide them with time estimates. “We estimate that it’ll take 6 hours at $200/hour for feature X and we’d do it like this…” The client will have to evaluate your estimate and figure out if it’s worth $1200 and make a decision. They can respond with, “no, that’s too expensive, can we do it for less?” The following steps would entail your team trying to find ways to reduce your estimate.
While these two paths might seem very similar, it’s been my experience that the standard approach to estimating takes more time for negotiating the terms of the agreement.
However, with timeboxing, you are asking your client to provide you with an initial budget. This will completely change how you respond to the feature request. When you have a timebox, from the moment that you begin to evaluate the request, your brain will add the necessary constraints to keep things within scope.
Through this process, we’ve revamped our estimating process so that as we’re building our iteration costs for clients. For each deliverable, we break down a series of objectives/tasks and apply timeboxes to each of those while knowing what the budget is for the deliverable as a whole. Usually, the deliverable is directly related to the request that came from our client with a budget. The process is completely transparent and our team is responsible for working within those constraints.
..and as we’ve learned from Ruby on Rails, constraints can be extremely beneficial.
While I don’t have all the answers yet, my goal is to share some of my experiences and lessons on the topic. I’d love to hear about how you’re adopting timeboxing in your project planning and estimating process.
Anyhow, just some thoughts that I wanted to share. More to come…
Read Related Articles
Enjoying the content? Be sure to subscribe to my RSS feed.
several of the tasks that we would budget hours for (versus estimate hours for) were proving to be more accurate
What do you mean by budget vs estimate? In particular I’m wondering what’s different if you budget/estimate a task to take 2 hours, you reach the 2 hour mark and aren’t done. In my interpretation of timeboxing, you would stop working and revert the incomplete work. If you estimated on the other hand, you would then reevaluate the problem and estimate remaining work to see if it’s worth it to continue. So what do you guys do when it turns out you under-budgeted? Or are you finding that the initial budget places a constraint that makes your developers more effective at estimating how long a task will really take?
The following steps would entail your team trying to find ways to reduce your estimate.
Can you elaborate on that? I guess this means you look for ways to reduce the scope of the feature as well. What else might allow you to reduce the estimate?
Looks like the key might be to break work into chunks estimated to take 4 hours or less.
Pat asks,
While this does happen, it happens less often than it used to. We rely on each of our team members to track their progress as they go. If they get half way through their timebox and aren’t feeling confident, they bring it up. If we need to renegotiate the terms with our client, we do this at that point in time. Often times, we can avoid this by trying to simplify it. However, if we don’t think we’re going to go over our mark by ~20%, we might just push through and finish it. The cost of redefining the scope of the deliverable might take longer than the additional cost in time. As I mentioned, we place timeboxes on smaller activities the collectively build a deliverable. So, our overages/underages are usually within a small handful of hours within a 100-150 hour iteration.
The goal here is to simplify the process so that:
It’s not a silver bullet. Nor is it a extremely different way to how you probably already handle estimating. What it has been for us is a way to establish scope early and use that as a guiding light throughout our process.
Okay so basically your developers are more accurate when asked “how much can you get done in X hours” as opposed to “how long will it take you to do task Y.” Does that sum it up? Seems reasonable.
Indeed.