- Must-Have
- Should-Have
- Could-Have
- Won't Have (even if you Want it!)
The problem with this scheme has always been getting stakeholders to specify their requirements as anything other than Must-Have and Project Managers to resource their projects so that there's anything other than barely enough time for the mandatory requirements. Just like my old boarding school - if it wasn't compulsory it was forbidden. Many agile practitioners have concluded that schemes like this which give user stories a priority value or category, are not worth the effort - just get the product owner to identify the next most important stories and we'll prioritize the other requirements later. I sympathise with that view but on a previous project I needed a way to introduce the idea of a "scope range" for each release of the software, and to do that I redefined the meanings of the MoSCoW categories.
Firstly Must and Won't:
Must-have (this release): If this functionality is not available by the release date, the release will be delayed.
Won't-have (this release): If all the other functionality is complete before the release date, we'll release early rather than start this work.
Should-have and Could-have both mean they will be attempted for the release if there's time. The difference between them is whether our forecasting predicts that it is more or less likely that they will make it. Thus:
Should-have (this release): Our forecasting shows a greater than 50% probability that the functionality will be included.
Could-have (this release): Our forecasting shows a less than 50% probability that the functionality will be included.
I felt this was a stepping stone for the client, to move away from deterministic and towards probabilistic planning. The main problem with the approach was that I was re-using a scheme that already had a publicly available definition and so in a large organisation there was no guarantee people would be using the definitions I had introduced.
A better approach now is to look to schemes based on the cost of delay of requirements. This again emphasises the probabilistic nature of forecasting and uses flow data from the process to optimise costs.
Firstly Must and Won't:
Must-have (this release): If this functionality is not available by the release date, the release will be delayed.
Won't-have (this release): If all the other functionality is complete before the release date, we'll release early rather than start this work.
Should-have and Could-have both mean they will be attempted for the release if there's time. The difference between them is whether our forecasting predicts that it is more or less likely that they will make it. Thus:
Should-have (this release): Our forecasting shows a greater than 50% probability that the functionality will be included.
Could-have (this release): Our forecasting shows a less than 50% probability that the functionality will be included.
I felt this was a stepping stone for the client, to move away from deterministic and towards probabilistic planning. The main problem with the approach was that I was re-using a scheme that already had a publicly available definition and so in a large organisation there was no guarantee people would be using the definitions I had introduced.
A better approach now is to look to schemes based on the cost of delay of requirements. This again emphasises the probabilistic nature of forecasting and uses flow data from the process to optimise costs.
No comments:
Post a Comment