An Agile Primer: Agile Estimating and the “MoSCoW Process”

An Agile Primer: Agile Estimating and the “MoSCoW Process”
By Chuck Snead

One common criticism of Agile Development methodologies by those used to more predictive methods is that Agile Development does not guarantee that all listed features will be completed by the end of a project. However, this is by design. What Agile Development does promise to do is to focus development on the features most relevant to the end users first, while providing the option to add more if time permits. This is an important distinction.

Because the end point of the predictive planning process for Traditional projects is a relatively inviolate development schedule, product owners and end users have been trained to take an “everything but the kitchen sink” mentality when converging on a solution, since the change control process tends to discourage the addition of more features once a project has been started. Product owners in Traditional projects also tend to have little control over the order in which features are produced, since development order is often determined more by efficiency of development than prioritization based on business value; the reason being that order shouldn’t matter, since everything is going to be delivered anyway.

However, in terms of usability and relevance, the development order does matter, since not all features speculated at the beginning of a project may, actually, be needed by the project, or even be relevant by the time they are deployed. Since expending development effort on activities that may not be needed or relevant at time of delivery is a significant source of waste, then a development pattern needs to exist that allows features to be prioritized based on the immediate need of the end users, starting with want they must have first, and working down from there. Enter the MoSCoW process.

MoSCoW is an acronym for prioritizing feature development along the following guidelines:

• 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.

An important differentiator in the above process is the term “required for success.” Some features will obviously be required, such as those needed to meet regulatory requirements. Others may be deemed required due to the percentage of end users who desire the feature. But the criteria for determining what is required should be as objective as possible. If a product owner merely “feels” something is required without evidence to back it up, then this is a feature that may more properly be defined as a high priority “should have” instead of a “must have.” The reason this distinction is significant is because it establishes an important milestone for determining the success of a project, Agile or otherwise, by focusing development initially on the absolute minimum set of features needed for delivery of a project, while making allowances for additional features if time and resource needs allow it.

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. The following are some helpful criteria for distinguishing must, should, and could:

• MUST haves consist of:
  • Critical core features required by the solution to function
  • Features required by law, statute, etc.
  • VERY high priority business requirements
• SHOULD haves consist of:
  • High priority business requirements
  • Highly desired features not defined as “must have”
• COULD haves consist of:
  • “Nice-to-have” features not defined as “must have” or “should have”

Once the stories have been grouped, the team will utilize some form of relative estimating, usually utilizing story points, to quantify the relative complexity of the stories on the backlog. Once this is complete, the team will then take 3-4 stories for which they have a high level of confidence and decompose those stories into hour and resource estimates, utilizing “ideal” time. The team will then divide the number of estimated hours by the sum of the story points used for the estimation to calculate an average hours-per-story-point. This average will then be multiplied by the total number of story points on the backlog to estimate the total number of hours needed to produce it. This can then be utilized to determine if the team can realistically produce all of the features identified on the backlog, or where to draw the line for that release of the project.

Depending on where the line is drawn (must haves only, must haves plus some percentage of should haves, must haves plus should haves, etc.) it is common practice to multiply the agreed upon total by a risk factor based on the assumed risk of the project. This provides a buffer to accommodate stories that will be discovered during development. Some typical multiplication factors are:

• Maintenance/recurring: 1.25
• Well defined: 1.5
• Extensive rewrite/new development: 2.0
• Quick start: 2.0 or greater

Thus if the sum of must haves and should haves for a well-defined upgrade project comes to 150 story points, the total projected story points for the project would be (150 * 1.5) = 225. If the average hours per story point for the project was estimated at 10, then the estimated hours for the project would be (225 * 10) = 2250 hours. This hour estimate would then be used to calculate the projected cost and resource requirements of the project.

Chuck Snead is a Project Management Professional (PMP), PMI Agile Certified Practitioner (PMI-ACP), and Certified Scrum Master (CSM) with over fifteen years of experience managing Waterfall/Traditional and Agile projects, for both the private and public sectors. He also has a Master’s degrees in both Information Technology and Business Administration, and he teaches various IT and project management courses as an adjunct professor. You can read more articles from Chuck on his blog.