It’s mid August, and suddenly there is a new website project. Get supertoybox.com live November 15 for the critical Christmas retail season.

At least they know what they want the site do. Supertoybox.com is a full featured e-commerce site with tons of features. So many features that it will take your team until the Christmas after next to get them all done.

And the kicker - you can only use internal, available staff… no additional resources, not even temps. That leaves you with a design team and development team of 5.

Ok. After a bit of chatting, it’s clear that there is no changing the project end date or the amount of folks that can get the work done. But there is something good. They do have a site design worked out and agreed upon.

They want to know if you can get it all done. Good question. So your next task is to estimate the proposed work. Here is what you came up with:

Um. That’s a lot of work. How much work? If each member of your team of 5 is very productive and cranks out 140 hours of dev time per month that’s a bit over 9 1/2 months worth of work. And there is just about zero chance of 5 folks delivering 6640 hours of work during a 3 month project.

But the good news is that each feature estimates include design, testing (usability, unit and system) and even customer approval – everything that needs to be done to get the feature ready to deploy. So everything we need to do to deliver the feature is in the estimate. Still, all that work isn’t going to fit into that little box.

That’s a serious situation. What is your plan to fix our little dilemma?

Lots of folks would just suck it up and say ok and proceed to work a lot to try in vain to get this project done… We have all tried this approach. Worked too hard for too long on projects with little chance of success. And it’s no fun and often turns out badly. Missed dates. Bad quality. Lots of bugs.

But there is a strategy that works great in this sort of situation…time box the project. So you ask, how does one “time box the project’?

To time box a project you simply:

  • Assign a non-changeable project start and end date,
  • Fix the project staff at a particular level,
  • Then implement as many features as possible knowing that some features aren’t going to make it in.

Ok. So, let’s apply time boxing to your supertoybox.com project and see how it works.

We already have a non-changeable end date of 11/15 and we are going to plan on starting 8/15. That gives us about 13 weeks of development time. That’s the length of our box.

And our staffing level is already fixed; we have 5 developers. Each developer is highly productive (85% of time spent at the office getting project work done) So lets figure they are going to spend 34 hours a working on this project. At that pace we will be cranking out about 170 hours (34 hours per week * 5 developers) of development work per week. That’s the height of our box.

Now it’s easy to figure out how much work we can get done. It’s the volume of our box, 2210 hours. (170 hours times * 13 weeks).

Now, if we can only complete 2210 hours of work before 11/15 then all we have to do is to get the project sponsors to figure out which 2210 hours of features they would like us to implement.

Then, you can just start on the other features after Christmas.

Sounds like a good way to solve this problem, huh? I think so.

And it gets better. The supertoybox.com project already has fixed end date and fixed resources… But if you time box ALL your projects - the content, the functionality and even the design ones, it’s really hard to sign up for more work than can be done. And, if you don’t sign up for more that can be done, the chances you will deliver successfully are higher.

But there is one problem we haven’t solved yet… How in the world are you going to get the project sponsor to cut the big list of features down to 2210 hours so that it fits in our time box? We are going to use MoSCoW prioritization, that’s how.

Website Project Time Boxing Resources

DSDM is one of the sources for the time boxing technique. But only has a passing mention of it in their e-book.

Agile advice has an interesting article on time boxing about episodes of Saturday Night Live.

Wikipedia has some good information on DSDM, time boxing, MoSCoW prioritization and iterative development.