In spring 1988 I travelled to the Union of Soviet Socialist Republics (USSR) for a week with my school. We flew from London to Moscow, stayed in the capital for a few days then took an overnight train to Leningrad (now St Petersburg), not far from the Finnish and Estonian borders.
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.
One misunderstanding that I’ve encountered a lot over the last couple of years in relation to DSDM agile project management is in the area of prioritisation, and in particular how MoSCoW prioritisation works. In this post I hope to make things a little clearer