Prioritizing work in the project with the MoSCoW method
Open source projects typically have more work to do than time to do it. So how do you decide what to do first? The easiest way is to let everyone work on what they find most interesting. This gives your volunteer contributors autonomy, which can be an important factor in keeping them around. Often this works out fine, but sometimes you need to work in a more coordinated manner.
The MoSCoW method
When working as a team, or even putting together a wish list of what you’d like to see people work on, how do you prioritize work? There are countless methodologies to pick from, and if you already have one that works for you, great! If not, I like the MoSCoW method. In the MoSCoW method, you put the work into one of four categories:
- Must have: the work that absolutely has to get done
- Should have: important, but not necessary work
- Could have: work that you’ll do if you have time
- Won’t have: work that you know won’t get done
Typically, you do this on a regular basis with a defined time that you’re working on. So you might do it each release cycle, or each month, or something like that. If you find you have a lot of the work in one of the first two categories, you get more strict and re-iterate. In most cases, you’ll find that very few things truly fall into the “must have” category.
What I like about the MoSCoW method is that it’s conceptually simple. The categories are easy to understand, with simple language that works regardless of someone’s English proficiency. It doesn’t require calculations or estimates.
Refining priorities in a category
The downside to the MoSCoW method is that it doesn’t offer any way to prioritize the work within a category. Of all of the “should have” work, which should you do first? As I wrote in chapter 1 of Program Management for Open Source Projects, there are a few principles that can guide your decisions.
- Prefer finishing work. If there you have multiple-stage features, it’s generally better to get one all the way done instead of starting on a new one. This fits the Unix philosophy of “do one thing well” and also gives your community a sense of accomplishment. Psychologically, it feels much better to have something done.
- Maximize the total benefit. Think about benefits in two dimensions: the number of people who receive the benefit and the amount of benefit they receive. Something that saves 100 of your contributors an hour of effort a month is likely more important than something that saves 10 contributors three hours a month.
- Reward the longsuffering. Of course, if the same 10 people keep not getting the benefits, they’ll get mad and go somewhere else. From time to time, you want to jump something to the top of the stack as a way to reward particularly hard-working or patient contributors.
- Expand the community. Work that makes it easier for new users or contributors to join will have a huge payoff in the long run. Like the “prefer usability” point above, the idea is to get people into the community so that they’ll stick around to help with future work.
Ultimately, though, you don’t need to spend much time worrying about prioritizing within a category. The “must have” work all needs to get done, pick anything and start doing it. The rest is optional, so do what’s interesting and/or easy.
