One agile practice that we’ve adopted from Scrum is that of product backlog refinement. In short, it involves representatives from both the project level team (project manager, business visionary, technical coordinator, etc.) and solution development team getting together periodically to review the prioritised requirements list (the backlog) to decide whether the upcoming features still have the same priorities, given what we’ve learned throughout the project so far.
This isn’t an entirely alien concept to DSDM, which recommends that “at the end of a project increment, all requirements that have not been met are re-prioritised in the light of the needs of the next increment” (DSDM 2014 onwards, paragraph 10.4.4). It simply gives it a memorable name.
As we approached the final two sprints of the digital pattern library (DPL) project (DC1001/2) we found ourselves with quite a few new requirements that had emerged from the work we had completed so far on the DPL. Many requirements were little more than ideas jotted onto a Trello card, or non-critical bug reports. Most had not been estimated. It felt like the right time to take a couple of hours out of the sprint to begin to get things into order for the next one.
First, we read through the cards to understand what they were about. Then we prioritised them. And last, we estimated them.
For estimation we use planning poker cards, which I wrote about in this article: Planning poker—why and how we estimate. It’s a simple, democratic technique that quickly helps build consensus. So, building on that success we adopted a similar approach for determining priorities.
Vote on priorities
With all our features in Trello, we switched on the voting power-up and each member of the team voted for the features we thought were the highest priorities.
There were six in the team, so we restricted ourselves to looking at only cards that received four or more votes—no point wasting time on features we didn’t consider urgent. (The Ultimello Chrome extension was useful for reordering the columns by number of votes.)
It was at this point we wanted to understand which features the team regarded as must haves (features that are important and vital), should haves (important but not vital), could haves (nice to have, but not important or vital), or won’t have this time.
MoSCoW planning poker
That was when we realised we could do something similar to how we run estimation planning poker, but for getting consensus on prioritisation.
We each took four packs of Post-it® notes and wrote on them: MUST, SHOULD, COULD and WON’T. That’s where MoSCoW prioritisation gets its name. We chose green for ‘must’, yellow for ‘should’, orange for ‘could’, and pink for ‘won’t’.
Then the MoSCoW planning poker game ran in very much the same way as it did later for estimation: select the next card, everyone chooses their preferred priority, once everyone is ready reveal your sticky note of choice, then discuss until consent is reached.
It was satisfyingly effective.
As with estimation planning poker it flattens the playing field: it puts everyone on the same level, gives everyone the same right to an opinion, and enables them to express it without feeling intimidated by more experienced team members.
I can certainly see us using this approach again in the future.