Agile game: MoSCoW prioritisation

I recently developed and presented a one-hour ‘master class’ on MoSCoW prioritisation. It’s not a hugely complicated topic, and one I have written about before. This time, though, I was able to talk people through the process of going from project priorities to increment priorities to timebox priorities, and how prioritisation leads to feature-contingency. As part of that presentation, I created a short exercise to demonstrate how to prioritise, the things you learn in doing so and the importance of having the right people present, including those who set the project vision and define the business case.

I created a set of 16 user stories and wrote them on 5″ x 3″ (127mm x 77mm) cards based on reverse-engineering a smartphone app. The app I chose was Pay By Phone but any application that has some practical real-world use would work just as well.

The game worked like this :

Ask delegates to work as a team, but without talking. Standing around a table, they need to place each of the 16 story cards into one of four columns headed “Must”, “Should”, “Could” and “Won’t”. This represented the prioritised requirements list for the project. Emphasise to the team that only the Must Have requirements are guaranteed to be delivered, so they should ensure that those requirements in the “Must” column represented their definition of the Minimum Useable SubseT (or Minimum Viable Product (MVP)). When a card switches columns more than once, pull it aside for later discussion. The game ends when all cards have been placed in a column and no more cards are being moved.

The objective of the exercise was to see whether the group understood the MoSCoW definitions and what comprised the MVP.

The exercise proceeded well and in less than 10 minutes everyone stood back from the table. There were two cards pulled aside.

The requirement to levy a charge each time a parking transaction was completed was a Must Have in one person’s mind (based on the assumption that this was how the app generated revenue) but a Could Have in another’s because he thought the app might be paid for.

I was surprised to see that one requirement – the ability to pay by credit/debit card – was also one of the controversial ones. I deemed it the core reason for the app itself and an essential part of the MVP. Someone else thought that the app was for booking a space, not for actually paying for it.

Both of these provided clear evidence of the need for a project Vision and/or Business Case before running this exercise in real life. Or at least called for the involvement of a Sponsor or Business Visionary / Product Owner to provide that guidance.

To my satisfaction, the two requirements I made up were allocated to the Won’t Have column, as they didn’t generate much value.

If you have played this game (or a variant) yourself, please tell me about it in the comments section below. If you’d like to see the user stories I wrote, just ask and I will send you a list of them.