Agile Software Development

Agile Estimating and the MoSCoW Process

One of the reasons agile works is because of how efficiently it prioritizes work, especially with regard to which features get built and when. It is by design that not every feature under the sun makes it into the final product. Writing for PM Hut, Chuck Snead recommends a process for helping to streamline estimation and prioritization even further, with the incredibly fun-sounding MoSCoW process.

Glory to Mother Agile

MoSCoW prioritizes feature development like this:

  • MUST have features that are required for the project to be called a success
  • SHOULD have features that have a high priority, but are not required for success
  • COULD have features which would be nice to have, but are not high priority
  • WON’T have features that stakeholders agree should be in a future release

The principle behind MoSCoW is objectivity. Those M-ust features need to derive their significance from things like regulatory requirements or a substantial number of users asking for it. Features that the product owner might intuitively believe are significant, but cannot be backed up by a hard reason, fall under the S-hould features. The difference between “must” and “should” is where a clear path to project success occurs, but MoSCoW also provides channels for adding bells and whistles where time allows:

MoSCoW does this iteratively by first utilizing brainstorming sessions to populate the backlog with features and user stories. The product owner and team will then group the stories by their must/should/could/won’t have status. This will lead to other stories being identified and prioritized until the team determines that a sufficient number of stories have been identified to reasonably quantify the project.

Story points or some other estimation form are then used to calculate complexity. After that, Snead says three to four high-confidence stories can be broken down into hour and resource commitments using “ideal” time. You can divide estimated hours by story points to determine average hours-per-story-point, which you can then place into the greater context of the project to understand how many features can actually fit into the backlog. Throw in a multiplication factor that addresses inherent project risks, and you have as good an agile map as you can hope for. Onward to MoSCoW.

You can read the original post here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.