Estimating versus Timeboxing, part 1
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
Alan Cooper @ Agile2008 slides
Alan Cooper, author of About Face, has slides from his presentation at Agile 2008 online.
If anybody knows if there is video of this talk, please let me know. :-)
Here are a few skitches from the slideshow.
Embracing Chaos, part 1
Consider this part one of several posts on my thoughts of the art of embracing chaos.
Don’t let the books fool you. The construction of custom software is an unmastered and volatile cesspool of chaos. I don’t adhere to the belief that there is a perfect methodology or process that will work for every project… as I’m sure many of you don’t.
Unlike bowling, you’ll never achieve a perfect score. Even in bowling, It’s unlikely that anybody will learn how to bowl a perfect score and do so on every game for the rest of their career.
You’ll never meet every expectation that a client has on every project.
You’ll never meet every expectation that a user has when they interact with your application.
Expectations are an interesting thing.
Your project might get widely adopted and embraced, but you’re still trying to control chaos.
It’s chaos. Pure chaos1.
So, why do we bother? Why do we try so hard when the odds aren’t in our favor?
To be continued…
Related Posts:
1 Chaos Theory, Wikipedia
Embracing Failure, part 1
I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.
“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”
I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.
Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.
Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?
“I thought that we paid you to fully test the code?”
Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.
What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.
Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!
IT’S OKAY TO FAIL! (some of the time…)
“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”
As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.
I’ll end this with a few questions, which I hope that you’ll share your experiences about…
- In what ways is your team embracing the failures of your development projects?
- How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?
We have so much to learn…
Poor Communication and IT Projects
InformationWeek has a short story titled, Poor Communications, Unrealistic Scheduling Lead To IT Project Failure.
“Communications failures top the list of reasons IT projects fail, according to poll results from the Computing Technology Industry Association.
About 28% of 1,000 respondents identified poor communications as the main cause of project failure, according to CompTIA, which offers project management training.”
So, while we’re all spending so much of our time focused on improving our technical skills, are we also investing our time into becoming communication superstars?
If you look back at the following posts, you’ll see some links to some excellent books on this topic.
Seth Godin on Dialogue
It appears that Seth Godin is catching on to the concept of Dialogue.
Seth writes, “Some organizations are good at listening. Some are good at talking. A few are even good at both.”
I’ve been spending a lot of time thinking about how I listen to clients, employees, friends, and family. All of our relationships are a series of conversations. Sometimes we can have healthy dialogue, sometimes we just fall victim to debate. (see Dialogue vs Debate)
If you’re really interested in Dialogue, I’d encourage you to review the technology of Dialogue... and check out the Dialogue-Driven Development project and introduce yourself.
