When I work on larger projects I like to make a clear description of what needs to be done, and more importantly the priority in which it needs to be done. Traditionally this would be done with a Project Plan. Usually done in something like Microsoft Project. However this is not very "aglie" and usually leads to spending hours managing a project plan and not actually getting any work done. It also leads to a ton of confusion about terms priorities and "who is assigend to what". So taking a step back, let's ask ourselves, "What does a prject plan really need?". The question is simple. We (Client and developer) need  a hogh level list of things that need to be done, and the prioirty that they should be given. I have found the best format is a MoSCoW document. 

A Brief Summary

A MoSCoW document helps determine what features are most important and which features are less important. When defining the different levels of importance keep in mind that the Must Haves, Should Haves, and Could Haves will all be developed, but Must haves will get done first, and the Should haves and Could haves will be the first to go if a time line or budget is at risk. One of the things that makes MoSCoW so great is that everything is defined in plain English.

Must Haves: These are things that must exist before I project can be considered complete. For example a car must have an engine before it can be considered a car.

Should Haves: These are the items that Should exist before a project can be complete. It is acceptable that these items be left out, but only if the project is seriously
at risk. For example, A car should have a windshield.


Could Haves: The items in this category are things that could be done with any extra time. The project really needs them, but if you have to choose between them,
these items are less important. A car could have a CD player.

Won’t Haves: This category is for all the things that you would like to see in the future but will not be in this revision of the project. Work will not be done to complete these tasks but no work will be done that excludes these tasks. A car Won’t have a DVD player, but we would like one in the future.

Keep in mind that the categories not only list items in order of importance if things have to be postponed or removed to meet a budget or other requirement, but also list a rough order of things to be done. Our car from above will get it’s engine first. Then it’s windshield, followed by a CD player. While we are doing all that we won’t install a dashboard to hold the CD player that will exclude us from adding a DVD Player later

An Example

For an example lets take a look at normal blog website. The client wants  the site to post stories about their vacation to Rome. They want to be able to post pictures and maybe some video. They want to be able to share the links on Facebook, and it would be nice to be able to give family and friedns special access to more personal posts, but have public posts for everyone else. So after a phone conversation or two we (both client and developer) work out the following document.

Must Haves:

  • Ability to post pictures with posts
  • Auto Post to facebook wall with new posts
  • Easy photo upload from phone

Should Haves:

  • Resize images to be sane for browser download
  • Private posts that can't be seen by the public
  • Ability to post videos

Could Haves:

  • Private access for family and friends
  • Auto post/pull videos to/from Youtube channel
  • Auto retreive photos from Dropbox's "Camera Uploads"

Won't Haves:

  • Use Facebook friends list to grant access to private posts.

In our example it's pretty clear what must be done and what would be really nice to have. With this very high level list, I, as a developer know what is critical to my client. The client also has a clear expectation of what is going to be done first, and where most of his money is going to be spent. As it gets closer to his vacation time, the prject is moving along quite quickly, and the client decides that Dropbox integration is more important then they they thought. So they move that one up in the list to a Should Have. At the same tme they discover that Rome doesn't have great internet coverage so they want to drop video support all together for now. So Video tasks go to the Won't have category. In this way, changes to the document allow for shifting priorities, at any stage of development, with out harming the project. It's vacation time and the website is ready. The client can post photos, make facebook posts and even has private access for family and friends. Theres no video support, but we can add that in later if the client gets some awesome videos of Rome, or not.  

In this way, a MoSCoW document allows both client and developer to understand priorities, without all the overhead of a system like MS Project and without having to worry about the low level tickets (tasks) that the developer will need to complete to get the project done. If you would like to see what your project would look like in this form just give me a call. It only takes a few moments to do and I usually do it as part of the quoting/estimating process. 

Coteyr.net Programming LLC. is about one thing. Getting your project done the way you like it. Using Agile development and management techniques, we are able to get even the most complex projects done in a short time frame and on a modest budget.

Feel free to contact me via any of the methods below. My normal hours are 10am to 10pm Eastern Standard Time. In case of emergency I am available 24/7.

Email: coteyr@coteyr.net
Phone: (813) 421-4338
GTalk: coteyr@coteyr.net
Skype: coteyr
Guru: Profile