This is another post in the spirit of the STEMGeek's Hackathon.
The prize pool for the Hackathon is over 12,000 Hive right now.
Using MoSCoW to improve project planning
There are a lot of useful techniques for brainstorming and project planning. One I don't see talked about too often is the MoSCoW analysis method.
MoSCoW is an extremely simple technique but can prove invaluable for new projects.
MoSCoW is a mnemonic device to remember four key categories for planning features for a project. While these are completely obvious when you hear them, actually identifying and classifying the features ahead of time will save a lot of headaches down the road.
It will also help you identify areas you can improve, don't need, or may not have considered prior.
MoSCoW simply means:
- Must Have
- Should Have
- Could Have
- Won't Have
By using these four categories you can categorize features for your project before getting too far along in development.
Must Have
These are features that are critical to the core functionality of your project. Without all of these features, the project is considered a failure.
If you don't identify exactly what is most critical to the success of your project, then you may need to rebuild a lot of functionality to support these features before you have a usable project.
Should Have
These are features that while not critical to the core functionality, the project really should support them to be competitive and successful.
Knowing what your project should do even before you start working on these features can allow you to design your database and interfaces to support features you know will be coming down the road.
Could Have
These are features that are nice to have but may not make it into the MVP (Minimum Viable Product) of your first release.
Identifying these features is good early in a project as some may require changes to how you store or work with core data. By knowing this ahead of time, you can frequently save a lot of time in the long run.
Won't Have
These are features you know your project will not have.
By identifying these features you know what functionality you do not need to implement or plan for.
I have seen the W also referred to as Would Haves which is a lower priority of the Could Haves. I believe Won't Have is more effective by identifying problems you will not be solving and leaving someday maybe for the Could Have.
While these categories sound simple (and they are), the exercise of identifying them and brainstorming will frequently help you see areas where you may have problems. You will frequently identify new features that can be very useful for your project that you never thought of before this exercise.
Even if you have started your Hackathon project, it isn't too late to give this technique a try.
