A large majority of the projects that I come into contact with start out with some sort of Gantt Chart. Whether it comes in the form of Microsoft Project or just Excel, this is something that is very common in the software development industry.
A typical project plan looks like this:
There's a list of tasks on the left, which are things like "Create Component X" or "Build Customer Search Screen." The next column shows the estimated duration of the task. These are time estimates that somebody (or some group) decided on at some point in defining the project. The chart shows the critical path of tasks in order to get an estimate of when the project will be completed. You can see that some tasks can be run in parallel, so sometimes delays on these will not result in delays of the overall project.
What's wrong with this? Under the right environment, one could argue that this would be very effective. This "right environment" generally looks something like this:
- You know exactly what you're going to build
- You know exactly how long each task will take
- The project won't change while it's underway
Hrm, this sounds a lot like bridge-building to me. But software development is different. We aren't building the same thing over and over again. If we were, custom software development would be almost non-existent. We don't know what we're going to build because our customers often don't know what they want!
There's a large component missing from this diagram. Something that our customers care deeply about. Do you know what it is? That's right, it's business value! Where is the business value depicted in this chart? Surely it's important. How else can we make scope changes and reorder the work if things aren't going as planned. This graph has everything already ordered. According to Gantt charts the business value only comes at the end of the project. Our customer doesn't know what "Code Component X" means. This is a developer task, and has no value statement associated with it.
Instead, what if we were to organize our work in terms of features. A feature certainly has some notion of value. You customer can easily tell you whether one feature is more important than another.
One could imagine a conversation like this:
You: George, we're looking at our current progress and it looks like we're not going to meet our May 18th deadline for your demo with the VC guys."
Customer: What?! Oh no this is terrible! They might cut our funding! We have to demo this stuff!
You: Well, if we were to remove one of these 3 features, we could finish on time and have a demo ready. Which one of these can wait a bit?
Customer: Well, it's critical that we are able to cancel a reservation. And I think that we also really need to be able to see the most recent reservations placed, as that is something that the client will do daily, but searching reservations seems like it will be important, but not critical. For now they can just find the reservations from the list.
Did you see what happened? Magic just happened, that's what. You and your customer just had a conversation about features and value. You're able to adapt to the project's progress and work on the most critical features first. The demo with the VC guys will happen and the most valuable features will be there.
How could this have happened in the Gantt chart above? We might be in the middle of "Code Component X" when the demo comes. Can we have the same conversation?
Lesson #1: Task-based plans don't convey business value. Feature-based plans do.
Okay, so now we have a list of features instead of tasks. Don't we still need to know what is required to implement each feature? Well yes, but not necessarily at the start of the project. Breaking features down into tasks is an ongoing activity throughout the life of the project.
What's next? Let's say we have 2 tasks on our project plan that look like this:
- Build the New Reservation screen (3 days)
- Build the New Booking screen (3 days)
Bookings and Reservations seemed like similar concepts, so we estimated them the same. So we go off and build the New Reservation screen and we get hit with some complexity. It takes us 5 days instead of 3. What do we do about the New Booking Screen? Is it likely that this screen will take us 5 days as well? Or do we suck it in and try and work twice as fast to get this one done in 1 day, so our project plan doesn't go off track?
Once an estimate proves incorrect, any other estimate based on that one is now incorrect. We can assume with high probability that building the Booking screen will take 5 days just like the similar Reservation screen. The problem here is that we've estimated these tasks in duration rather than size.
Instead, let's give the Reservation screen an arbitrary number, like 5. 5 What? I don't know... 5 Bananas. 5 Gummy Bears. 5 Stars. Whatever it is, a 5 should mean something. What's a 5? It's about the size of that Reservation screen. Oh ok, so this Booking screen must also be a 5. And this Order Fulfillment screen, that's twice as big, so let's call that a 10. What we're doing here is estimating in relative complexity, which far more stable a number.
Human beings can discern the size of something much more effectively than the time it will take to build it. And as things progress on our project, the size generally stays constant. We won't have to re-estimate these tasks unless the size changes.
Lesson 2: Estimate in size, not duration.
OK, I can already hear you saying "But how can we tell our customer how long it will take if we don't estimate in duration?" -- Well we do estimate in duration, but we also convey the confidence in this estimate.
Customer: So how long will this take?
You: I don't know, we still don't have enough information about what to build, so I can't give you a firm number.
Customer: Well I have to know, how long do you think it will take?
You: My best guess? 3-6 months.
Customer: 3-6 months? That's a big difference!
You: Absolutely. We are estimating this at the worst possible position in the project. Let's assume it will take 6 months for now. After every iteration (2-4 weeks, typically) we will give you a more educated guess.
Granted, not all customers will be willing to do this, but you can spend more time discussing the process than I have here.
This is where Burndown charts become so effective. A Burndown chart looks something like this:
This chart shows the hours remaining to complete the work during a given iteration. Let's assume we attempted to complete 67 points (or Gummy Bears, whatever you decided on) of features. When planning for hour iteration we broke these down into tasks and the team estimated 420 hours worth of work. At the end of each day, the developers estimated how many hours remained on the tasks they were working on. This continues every day. Sometimes we uncover hidden work and this chart goes upward, as you can see in the picture. Regardless of what we planned to do with our best intentions, we want to see actual performance. If you were managing this project, would you feel comfortable with the current progress?
Try plotting a slope line on this image to see where we're headed. Also plot the ideal line if we were to be on track.
We're about 1/3 done with our first iteration, and we can already make solid assumptions of where we're headed. It's clear that we aren't going to make our target, so it's time to have that conversation with our customer on what to pull. This graph might also depict that we'll finish way too early, in which case the customer would be invited to select an extra feature to be developed in that iteration (provided the feature would fit in the slack room we had).
This chart shows clearly what is going on in the project, and you can easily expand this chart to encompass the overall project, not just the current iteration. What if this graph represented the overall project and we were 1/3 done. What would you do?
- you could cancel the project -- it sucks, but it's better to get out now than to start a death march project that ultimately won't finish in time and won't help the business. Better to lose $150k than $500k any day of the week.
- you could cut scope -- maybe changing the icons to cornflower blue wasn't as crucial to the business as we thought.
- you could remove impediments -- what if you found that the developers are all experienced ReSharper users and they could be more productive if they all had licenses? What if we had trouble getting a hold of the domain experts and we were waiting too long to get answers? We could make some changes there to streamline the process. Most business have a ton of fat in the process. We just need to find it and cut it out.
- you could add more resources -- if the end date is firm, then we might add some new folks to the project. This is a bit of a dangerous move, as adding too many people to a project tends to make it later, but in a lot of cases, and extra pair of hands will help. We can ask the team what type of person they need and try to fill that role.
This type of actual progress vs. planned progress reminds me of that great scene in Apollo 13, where Ed Harris' character is asking whether or not a spacecraft could do what they were asking. A squeemish representative cowardly states, "The LM was not designed for this..."
"I don't care what it was designed to do, I wanna know what it can do!"
The original plan is only useful enough until it doesn't represent reality any more. What is useful is our empirical data. Our actual progress. That allows us to make informed decisions about what to do next.
Lesson 3: Actual progress is infinitely more important than planned progress.
At the end of a few iterations we'll get a pretty good idea of how many points we can complete in an iteration. This number is our velocity.
If we have identified 600 points of features to complete until we're "done," and we're completing an average of 60 points per iteration, then it doesn't take a rocket scientist to tell that we'll be done in 10 iterations. That's a powerful statement. After a few iterations you can tell your customer, "based on our current velocity and the amount of work we've identified, we'll be done July 27th." The next iteration this date will get closer and closer to the actual "done" date.
Lesson 4: Calculate your velocity and use that to plan for the future.
Burdowns (along with other related practices and ideas) are an incredibly effective tool to help you reign in your out of control projects. Plans, road-maps, and timelines are all effective tools until they're not reality. Learn from your past performance and project this onto the future.
I've only scratched the surface on how to effectively use burndowns on a project. Some other important aspects are defining what "done" means and continuously improving the process. If you're interested in implementing burndowns, I highly recommend you read these books: