If there was ever a clear way to achieve success on a website project, it is iterative development. Not just success but success with a decreased risk of project failure and increased quality. It doesn’t get any better than that.

Iterative development makes projects successful by slicing the time available for a project into a series of smaller time-boxed projects called iterations. Then each iteration is scheduled to deliver as many features as possible that are 100% complete and ready for deployment.

The approach of simplifying a project into iterations is a great idea. And, there are lots of other compelling ideas baked into iterative development. For instance:

• Focus on short term, achievable goals - Big projects can be overwhelming for all those involved. They are just like big elephants; trying to eat the big elephant in one bite isn’t going to be pleasant. But cutting the project into small bite sized chunks helps keep your team focused on small, short term, and achievable goals.
• Get good at finishing – Getting a chunk of work all buttoned up and complete is hard. It’s a skill that every team needs but few really perfect. By completing two or more iterations per project which have to deliver completed functionality, your team will get really good at finishing because they practice doing it so much.
• Reduce risk by doing the important stuff first – One of the first things you learn as a project manager is to schedule the high risk and important features early in the project. Why? Because if something important gets screwed up early in the project, then you have time to improvise and recover. But if things get screwed up late in the project then it’s pretty unlikely you are going to finish on time. Iterative development enables you to schedule the important stuff first and get it completely done early in the project, which substantially reduces project risk.

Together these ideas blend together into something really nice. How do you apply it? Let’s revisit our supertoybox.com example we have been working on for a while…

Supertoybox.com is an e-commerce website project we have time boxed to begin 15-Aug and end on 15-Nov. That gives about 13 weeks to work with. We have 5 dedicated resources and after a bit of math that figures out to be a time box of 2210 hours.

The site has a page template designed already. We have developed a domain model and high-level design so we could get accurate feature time estimates. Each feature estimate includes design, development, testing (usability, unit, system) and deployment. This will make our iteration planning much easier.

We have also done a MoSCoW prioritization to establish the priority and importance of each feature. Our task at hand is to plan the iterative development efforts for the project.

How to Plan Iterative Website Development Using MoSCoW Prioritization and Time Boxing

1. Establish length of Iterations
Our first big decision is how long we want to make our iterations. Any project needs to have at least 2 iterations and we want our iterations between 2 and 6 weeks in length. We also want them to be as small as possible and each of them to be the same length. Seeing that we have about 13 weeks in our project, let’s try 6 two-week iterations, which would make each iteration about 340 hours long.

2. Schedule the “Must have” features
We want to schedule all the “Must have” features early in the project. This gives us two big advantages. First, if we deliver all the “Must have” features early our project is assured of success. (MoSCoW prioritization defines success as a project completion with all the “Must have” features complete) Second, if we screw something up and don’t deliver a “Must have” feature in its scheduled iteration we can try to get it done in a later iteration. We have time to recover if something goes wrong.
Scheduling the “Must have” features ends up with a pretty busy iteration 1, 2, 3, and 4:

If things are going well at the end of iteration 4 we will be done with all the “Must have” features and will be into working on “Should have” features. This would put us into a great situation where we are done delivering the important stuff and we will be down to making the website work better about 2/3 of the way through the project. Sweet.

3. Schedule the “Should have” and “Could have” features
Our goal is to schedule all the “should have” features then schedule as many “Could have” features as possible. It’s normal, even good, to have more features ready to be implemented than you have time. That way if there is more time available in an iteration at the end of the project, you can easily try to include more features.
But if you are running behind at the end of the project, then fewer features get done. The idea is that you are trying to get done as much as possible, but projects are dynamic and you won’t know exactly what will get done until you’re well into the project. So simply add the “Should have” features into iteration 5. Something like:

Then, stack the rest of the features into iteration 6 in order of importance. Something like:

Then sometime in iteration 4, meet with you team and try to figure out what you are going to attempt to get done in iteration 5 and 6. In other words, plan to improvise.

Iterative development really works well in this example. We get the important stuff done early and have time to recover if something goes wrong. We also have plenty of features to implement that will really improve the website if we have time at the end. And, if we have available time earlier in the project it’s possible we could even move features up to those iterations too - An ideal situation.

This is the last in the “Larry, Moe and Curly of Agile Web Projects” series where we quickly ran through using the time boxing, MoSCoW prioritization and iterative development techniques together. It has worked out really nicely. We have delivered as much as can be delivered in our time box. What gets delivered is exactly what the business wants and we have reduced our risks along the way. If you agree, then why not give it a try and let me know how it goes…

Iterative Website Development

The broad spectrum of iterative development are discussed in the article, “Going round and round and getting nowhere eXtremely fast? Another look at incremental and iterative development“.

The XP crowd’s view on the “History of Iterative Development”

How is iterative development different increment development? If you really want to understand anything agile or project management in depth then consult this Alistair Cockburn article, “Increment versus Iterative Development”

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

Because DSDM gives their methodology to folks that join the DSDM consortium (which seems a lot like selling it really) there isn’t a ton of books about it. The best book about DSDM that I have found is DSDM Business Focused Development .

If you are up for something brief and about the latest version of DSDM, called Atern, the best book about DSDM isn’t really a book. It’s a little pocket guide. Easy to read and high level enough for anyone.

First off, MoSCoW prioritization isn’t from Russia. And it’s not communist either. It’s an agile project management technique that is part of the DSDM agile project management methodology.

And one of those part acronym, part word, words. MoSCoW is short for “Must have, Should have, Could have, Won’t have”

Not only is MoSCoW a funny acronym, its best way to figure out which features should be included in a project. Its true value is found when combined with project time boxing. This makes sense because project time boxing and MoSCoW prioritization are designed to work together by our friends at the DSDM Consortium.

The underlying ideas behind MoSCoW prioritization are worth talking about before we launch into an example of it’s use. That way it will make a lot more sense when you go to implement MoSCoW prioritization yourself. Some of the ideas behind MoSCoW prioritization are:

• Less might be more – Have you heard the saying “80% of the solution comes from 20% of the functionality?” You and I both know this is true; there is a small number of features, often known as a minimum usable subset of features, that make a website work. The rest of the features are “nice to have.” MoSCoW embraces this idea by first figuring out what the minimum usable subset is and then classifying the rest of the features important but not critical.
• Workarounds are ok – It’s often painful to defer a feature until a later release. But is it a good idea to put a project at risk of non-delivery to implement a feature that could be worked around outside of the website? Nope. When using MoSCoW prioritization, features that are not part of the minimum usable subset can be worked around if they don’t make it in the final result of the project.
• Deliver value early - All project features are important. Everyone would agree they should be prioritized to deliver the greatest and most immediate business benefits early in the project. With this in mind, MoSCoW prioritization establishes the priority order in which to deliver project features instead of delivering what makes sense from a development perspective.
• Cutting features isn’t much fun – Getting anyone who wanted a particular feature in a website project to cut it completely out of a project is a tough sell. However, prioritizing a feature against the other features in the project to figure, which must, should, or could get delivered by the project is a lot easier. MoSCoW embraces this idea by having multiple levels of priority for features in a project not just “in the project” or “out of the project”

These approaches make so much sense to me. What’s also nice is how easy it is to figure out. The most basic part of MoSCoW prioritization is the categorization system. Each feature can be categorized “Must have”, “Should have”, “Could have”, or “Won’t have”.

Anything labeled as “Must have” has to be delivered in the project time box for the solution to be of use. In fact, lots of folks think the “Must” in “Must have” is an acronym “Minimum Usable SubseT” of features. “Minimum Usable Subset” of features is the minimum amount of functionality that will solve the business problem at hand. However, if all the “Must have” features are complete at the end of the project the project must be considered a success.

”Should have” feature are items are nearly as important as the “Must have” and should be included if it is at all possible. “Should have” items are often as important as “Must have” features but have workarounds allowing another way of satisfying the requirement.

”Could have” features are less critical than “should haves” and are “nice to have.” But, a few “Could have” features in the project can substantially increase customer satisfaction.

“Won’t have” features are either not critical or low return features. “Won’t have” features won’t be delivered in the current project and are deferred to the next project.

DSDM advises keeping “Must have” features hours fewer than 60% of the total project hours. And “Should have” and “Could have” features should be about 20% each of total project features. In higher risk scenarios, like a really tight timeline or a deliverable with numerous risk issues, I would try to keep “Must have” features down to less than 50% of the time box.

One thing that DSDM does not advise is to let the total project feature hours (the number of hours for features prioritized Must, Should and Could) exceed the total hours in the time box.

But experience tells me that having more project feature hours prioritized than time box hours is a good idea. In fact, I find it’s ok to add up to 50% more project feature hours than time box hours.

Why allow a project to have more project feature hours than the time box hours? Well, by their nature your estimates for each feature should be conservative. And what if things go better than expected and the project can deliver MORE than originally expected? If this happens, it’s good to have some features already queued up and ready to implement.

So the next question how do you do it?

How to Use MoSCoW Prioritization in an Agile Website Project

Let’s revisit our supertoybox.com e-commerce project we talked starting working through in the last article about time boxing.

So far, the supertoybox.com project has a large defined set of features we need to prioritize for the first site release on 11/5, just in time for the Christmas season. Here is our feature list:

Using some simple calculations, our timeframe of about 13 weeks and 5 resources cranking about 170 hours a week gives up a project time box of 2210 hours. Given that, our mission is to prioritize the list of features and end up with about 2210 hours of work that will yield a good first release of the supertoybox.com website.

1. Prioritize “Must have” features - On the first pass through the list I like identify the “Must have” features. At a minimum our site has to have a basic product catalog, search, and a shopping cart with tax and shipping calculations. We will also need to do credit card transactions, have some way of getting orders out of the system and a page framework to hang the functionality on. That’s pretty much the bare minimum. So our first pass looks like:

Using this initial prioritization, the “Must have” hours they are about 57% of total time box hours, which is about where we want to be.

2. Prioritize “Won’t have” features - Next, I like to see what I can easily defer out of the project to make it nearly the size of the time box. I try to look for large features than can be worked around and are not technically required to make the project work. For this project I would look to defer system integration and do manual order entry. We can also safely defer the reporting and statistics feature because we could likely get that information from our ERP system. Features like multiple address shipments, product category admin and the wish list can also safely be deferred. That puts us with a prioritization like:

After deferring these features, our project is down to an estimated 2240 hours, which is just about 1% larger than our time box. That’s good.

3. Prioritize the “Should have” features - “Should have” features complete functionality that are categorized “Must have.” I’d look at browse product by age, the CVV2 and paypal and shipping confirmation emails as very important but not critical features to include in this first release. Now our prioritization looks like:

4. Prioritize the “Could have” features - I like this step; all the rest of the features are “Could have” features by default. That puts us to a completed prioritization that looks like:

We get pretty lucky on this project because the “Won’t have” features are pretty easy to defer and the “Must”, “Should” and “Could” features are not much bigger than the 2210 time box:

At first glance, we have enough time to deliver the 1260 hours of “Must have” features in our time box of 2210 which ends up at 57% of the total time box hours. That’s good. The total project feature hours for this release is only 101% of the time box hours.

But, how do we make sure that we can deliver ALL the “Must have” features and pack in as many of the “Should have” and “Could have” features as possible? Let’s try out iterative development to see what that can do for us.

MoSCoW Prioritization Resources

DSDM has great resources on MoSCoW prioritization in Atern and MoSCoW prioritization in DSDM version 4.2.

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

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 has great resources on Time boxing in Atern and time boxing in DSDM version 4.2.

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

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

The Three Stooges. The Three Tenors. ZZ Top.

All of these trios are memorable and for good reason. Each member is an outstanding individual contributor. Each trio has found a unique synergy. And they have all created masterpieces in their respective fields.

And let me add one more memorable trio: Time boxing, MoSCoW prioritization and iterative development.

Although not people these three practices are just like other memorable trios. Is each member an outstanding individual contributor? Check. Unique synergy? Check. Create masterpieces? Check. Yep, Time boxing, MoSCoW prioritization and iterative development are a great trio too.

So, do other folks think these practices are a great trio? Well, creators of the DSDM agile project methodology think they belong together and call them “key principles.” And they are all individually recognized as sound practices as more of these practices are in every single agile project methodology.

So why bother with implementing all three of these practices? Couldn’t you do less and be ok? Yep, you could do less and implement just one of these practices and it is going to help improve your projects.

But when implemented as a trio these three magical processes are so powerful that they can literally transform how your projects work.

And Time boxing, MoSCoW prioritization and iterative development will do these major transformations for any content, design and functionality website project that comes along.

And what is even more amazing after some serious thought is that it’s clear to me that time boxing, MoSCoW prioritization and iterative development are a lot like The Three Stooges individually and as a trio. Wacky, huh?

Time boxing is a lot like Moe. Moe was the leader and set the tone for The Three Stooges, just as time boxing does for our agile trio. But, time boxing seems a bit smarter than Moe.

A bit smarter because the time boxing technique acknowledges that almost every web project arrives with fixed end dates and limited staffing flexibility. Instead of trying to fight for more time and resources, the fixed end date and limited staff are considered a “time box” that can’t be modified.

Then your job is to fill the time box with the most important features that will fit inside. This approach turns your typical project startup discussion from “I need more time and more people for this project” into “ok, I can accept the dates and not hiring anyone. But, we need to talk about limiting the features that can be delivered.” I find talking about which features to deliver instead of time and resources a refreshing change. And, I bet you will, too.

MoSCoW prioritization is a lot like Larry. Larry gets most of the slaps and without him the trio just doesn’t work. Just like Larry, without MoSCoW prioritization, iterative development and time boxing just don’t work either.

MoSCoW prioritization sorts the features in your project by business value and then groups them into four buckets: “Must have” features must be present and complete for the release to deliver any value at all. Your project should be considered a success if you can deliver all the “Must have” features.

“Should have” features are important but have a workaround if they don’t make it into the final release. “Could have” features are “nice to haves” but do help increase customer satisfaction. “Won’t have” features are considered deferred until a later project.

Although this prioritization isn’t anything magic, it gives you critical information needed to fill your time box and assure successful delivery of the “must have” features. Then it helps you maximize the use of any project time left to complete “Should have” features and finally, the “Could have” features.

There are lots of ways that Curly reminds me of iterative development. Curly was the breakout character of The Three Stooges; he was the guy that made them famous. Just like Curly, iterative development is the breakout practice of Agile project management. Still today, most folks think of iterative development when they think of agile project management.

And Curly made sure every scene was success for The Three Stooges by on screen improvision. Iterative development makes sure your project will be a success by making it more likely that all the “must have” features will get delivered and as many of the “Should have” and “Could have” features as you can fit in.

Iterative development makes projects better by slicing the time available for a release into a series of smaller time boxed projects called iterations. Then each iteration is scheduled to deliver as many features as possible, which are completely finished and ready for deployment.

Planning iterations completely relies on the MoSCoW feature prioritization. First, we want to schedule the “must have” features into iterations that occur early in the project. This substantially increases the chance of getting ALL the “Must have” features done.

Once the “Must have” features are scheduled into the early iterations we want to schedule the “Should have” and “Could have” features into later iterations. Because features are added in order of priority, as established during the MoSCoW prioritization, all of the iterations are filled with features the business folks really want. And they get really happy when you give them what they want, don’t they?

So there you have it, using our agile trio you have a whole new way to make your business folks happy. Time boxing, MoSCoW prioritization and iterative development are proven techniques that increase your chances of successful project delivery. And they work together to maximize the amount of value your project can deliver in a way that actually decreases the chances of project failure. Good stuff.

But how do we apply these practices? Let’s talk through each using an example project and get the details on Larry, Moe and Curly time boxing, MoSCoW and Iterative development.

Time box, MoSCoW prioritization and Iterative Development Resources

The DSDM consortium creates the Dynamic System Development Method. The new version of DSDM is called Atern. (login required). You can also access the older version of DSDM (version 4.2) using the same login.

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

Because DSDM gives their methodology to folks that join the DSDM consortium (which seems a lot like selling it really) there isn’t a ton of books about it. The best I have found is DSDM Business Focused Development.

If you are up for something brief and about the latest version of DSDM, called Atern, the best book about DSDM isn’t really a book. It’s a little pocket guide. Easy to read and high level enough for anyone.