If you find this site useful, you should try my 55-page eBook here

Prioritization using MoSCoW

by Kelly Waters

Email This Post Print This Post Save As PDF
Prioritization using MoSCoWSeveral years after I first encountered it, I still find MoSCoW one of the easiest methods for prioritization...

The MoSCoW approach to prioritization originated from the DSDM methodology (Dynamic Software Development Method), which was possibly the first agile methodology (?) - even before we knew iterative development as 'agile'.

MoSCoW is a fairly simple way to sort features (or user stories) into priority order - a way to help teams quickly understand the customer's view of what is essential for launch and what is not.

MoSCoW stands for:

Must have (or Minimum Usable Subset)
Should have
Could have
Won't have (but Would like in future)

'Must Haves' are features that must be included before the product can be launched. It is good to have clarity on this before a project begins, as this is the minimum scope for the product to be useful.

'Should Haves' are features that are not critical to launch, but are considered to be important and of a high value to the user.

'Could Haves' are features that are nice to have and could potentially be included without incurring too much effort or cost. These will be the first features to be removed from scope if the project's timescales are later at risk.

'Won't Haves' are features that have been reqeusted but are explicitly excluded from scope for the planned duration, and may be included in a future phase of development.

It's a good idea to make sure a project has a healthy number of Should Have and Could Have requirements. This helps to provide the project with some flexibility if things start taking longer than expected, effectively providing the project with some contingency.

If a project only has 'Must Haves', the scope cannot be varied. Therefore the cost and timescales should not really be fixed without including a reasonable contingency. 'Could Haves' can be that contingency. They are effectively stretch tasks; features that will be included if possible, but the launch date will not be moved to accommodate them if there is not enough time to complete them.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
keep up by rss feedkeep up by email


Photo by serjio r

  • Digg
  • del.icio.us
  • StumbleUpon
  • Yahoo! Buzz
  • Technorati
  • Facebook
  • TwitThis
  • MySpace
  • LinkedIn
  • Live
  • Google
  • Reddit
  • Sphinn
  • Propeller
  • Slashdot
  • Netvibes

0 comments:

    10 Key Principles of Agile Development

    How To Implement Scrum in 10 Easy Steps

    User Stories - Agile Requirements

    Agile Project Management

    10 Key Principles of Agile

    How To Implement Scrum

    Most Read

    Agile Leadership

    Agile Requirements - User Stories

    Agile Estimating

    Agile Testing

    Agile Project Management

    Lean Software Development

    Agile Teams