Planning for Feature-Complete Deadlines

Next week I will be on vacation in Sweden. I am really looking forward to that. If the northern part of Sweden allows it, you can expect tweets from me while driving in our huge rented Volvo, or while attempting to put up our tent, cursing and swearing. Or while swimming in one of Sweden's many lakes, au naturel, scaring away all the fish. Except the blind ones.

But first I have to do some vacation planning and risk management.

My plane leaves at 6:55 in the morning next Wednesday. How late do I need to get up?

I know that the time between getting out of bed and entering the plane is about two hours when everything goes as planned. So, will I get up at 4:55? Of course not! Things never go as planned, do they? I know (from personal experience) that halfway to the airport I might have to return home to fetch my passport. Or my car (and me) might suffer a flat tire. Or two. Or there's going to be a huge traffic jam. Or at the check-in desk there's going to be a family before me with three children, six suitcases, 22 items of hand luggage, a doggy house, and a refrigerator. (And they will want to negotiate the charge on surplus baggage too.)

Planning to catch a plane is a perfect example of risk management for contained change: problems are expected, but they usually fall within a range you can still make an estimate of. (I wrote about this in my post The Three Types of Change.) Using experience I can make a probabilistic forecast of the time required to catch the plane. It will take two hours at the least to be there on time. But when Murphy's Law hits me (and it usually does in some way) it could be anywhere up to four hours.

So, what time will I get up?

Exactly… 2:55

Maybe 3:25 (when I'm feeling bold and confident)

Planning to catch a plane is like planning for a feature-complete deadline. Unless I'm flying with Air Force One, the plane is not going to wait for me. And when I arrive at the gate it has to be with a minimum set of requirements: passport, ticket, baggage, etc.

It amazes me how few customers and project managers apply similar probabilistic risk management when planning for a feature-complete deadline. They get an estimate from a development team that says "We could do this project in X weeks when everything goes as planned". And then the team, project manager, and customer negotiate a project deadline at X weeks + 1 day.

Why? It doesn't make any sense.

I don't set my alarm clock at 4:55 either, do I? People would call me a fool if I did that.

Yes but, I hear you say, we are going to do the project with Scrum! So we have a potentially shippable product every sprint, and we could skip the least important features when we're running out of time. And then I would reply: of course you must do that! But Scrum and agile won't help you with a feature-complete deadline…

When I'm running out of time while trying to catch a plane, skipping the parking of my car and simply leaving it at the terminal entrance is not an option. And neither is throwing away my suitcase so I can skip the check-in desk, nor running past the security check, or sneaking past the line for customs. You are required to do all of that and catch the plane too! You could skip breakfast and coffee when things go wrong, but that's about all the leeway you have.

Many product releases must contain some minimal set of features, or otherwise their release won't have any value at all. In such cases project managers and customers must apply probabilistic risk management. Agile planning cannot save their behinds by skipping features. In such cases there's one-and-only-one risk management approach:

1. Make an estimate for the minimal set of features (the Must-Haves);
2. Pad this estimate using your experience (which could mean: double it or even triple it);
3. Use that new number for your release planning towards the deadline.

If you do this well, the slack you've built in should give you plenty of time for an agile approach towards all your Should-Haves and Could-Haves, like breakfast, coffee, and tax-free shopping.

The amount of Must-Haves can vary wildly per project. Some don't even have any. I can apply agile planning to my whole trip through Sweden, because all the interesting things we intend to do are Should-Haves and Could-Haves. Except, of course, the parts where I go swimming in the lakes. After all, without the swimming there would be no point going to Sweden.

(Note: during my vacation I have some slots available on my blog for guest posts. Contact me if you're interested. Your guest post should be related to managing software development, or swimming in Swedish lakes, and I'd like to receive the final version on Tuesday, with a first draft on Sunday or Monday.)

(image by Per Ola Wiberg)

 Twitter –  Subscribe – Newsletter – Bookmarks

Latest, greatest and favoritest posts:
The Three Types of Change
Agile is NOT a Risk Management Strategy
Agile Is a Risk Management Strategy