I hope I have the time to come back to this thought tomorrow (along with some overdue Thanksgiving blogging). But I had the opportunity to meet up with an old colleague for lunch today and to discuss, among other things, two different agile project cycles. One project cycle ships every four to five months, has seven or eight two-week iterations inside the release cycle, and uses MoSCoW-style prioritization (that is, Must, Should, Could, Won’t) for feature stories and for backlog. The other ships every six weeks, has one iteration inside the release cycle, and uses forced stack ranking for feature stories and backlog.
Which of the differences (iterations per release, release length, prioritization) is most important between the two projects? Which has the greatest impact on the release?
I’m going to give away the answer when I say I think there’s a stack rank of impact:
- Prioritization method
- Release length
- Iteration frequency
Why is prioritization so important? And which method is better, forced stack ranking or must, should, could, won’t?
The problem with any bounded priority system, whether it’s MoSCoW, Very High/High/Medium/Low, or simply 1, 2, 3, 4, is that it leads to “priority inflation.” When I was selling ITIL compatible software, we had a feature in our system that used a two factor method and customizable business logic to set priority for customer IT incidents. It was necessary to go to that length because, left to their own devices, customers push everything inexorably to the highest priority. Why? Because they learn, over time, that that’s all that ever gets fixed.
It’s true in software development too. I can’t count the number of features that were ranked as “must haves” on the project that used MoSCoW. It was very difficult to defend phasing the work, because everything was a must.
The project that uses forced stack ranking doesn’t have the problem of too many “must haves” because there can be only one #1 priority, and only one #2, and so on. Developers can work down the list of priorities through a release. If there’s been an error in estimation and the team has overcommitted for the release, it’s the lower priority items that slip.
The forced stack ranking works with stakeholders outside engineering too, because it forces them to evaluate requirements against each other in a systematic way. Rather than saying “everything is a must,” stakeholders can give answers about whether requirement A or B is more important within the scope of the release.
Release length and iteration frequency matter, too, because they provide mechanisms for market-driven and internal-driven course correction. But from my experience, as long as the release length and iteration frequency aren’t too far out of whack, the right prioritization method is a crucial ingredient for successful delivery of software that meets stakeholder expectations and for defining feature lists that have a reasonable shot of getting completed within a single release.