At last the requirements are gathered, the project is sized and everyone’s restless to get the ball rolling. Now even one optimistic glance at the long list of user stories makes you certain they’re impossible to accomplish within the given time frame. So our next stop is prioritization of the Product Backlog.
Prioritizing: a key to success
Why prioritize? We’ve all sworn on Agile Manifesto to deliver maximum business value ASAP. The shortest path to production is by building a minimum viable product (MVP). And that is impossible without Backlog refinement.
How to prioritize? While the client and stakeholders know how much value each story may bring, the developers are experts on the amount of work, complexity, and risks involved – in other words, what the total effort of implementation will be. How those two criteria interplay in achieving success is not always obvious. Thus prioritization has a collaborative character. Let’s have a look at some Backlog grooming techniques that proved useful in Agile prioritization.
MoSCoW analysis
The technique got its name from abbreviating the four modal words showing attitude to backlog items as ‘must-haves’, ‘should-haves’, ‘could-haves’, and ‘won’t-haves’. The notions are universally understood – hence the popularity.
Casting the features into the four categories rates the end-product’s functionality as:
- Must-haves – an absolute minimum guaranteed to be delivered that will constitute an MVP. Without them, the product will not correspond to the definition of Done for at least one of the reasons: safety, law, quality or business value.
- Should-haves – not vital, but important features. Those are highly desirable because of their high value to stakeholders or end-users.
- Could-haves – less impactful on the final product if left out.
- Won’t-haves (this time) – not planned, but still important to document in case they might be reintroduced later, so that everyone has proper expectations about the release version.
Successful implementation of the technique depends on clear and firm distinction of the above four categories and mutual consent on every feature status once the Backlog gets refined after each iteration.
It’s equally important to keep the ratio of 3 : 1 : 1 between must-, should-, and could- categories of items to allow for contingencies.
MoSCoW method, if properly applied, empowers both the client and the dev team with a proper development perspective by providing criteria of a project’s success.
A more detailed description here.
Cumulative Voting
Cumulative Voting (aka ‘The Hundred-dollar test’) consists in ‘buying out’ ideas by a special ‘idea currency’ allocated to all the participants – $100 each. The more value is attached to an item, the higher the priority. By limiting the amount of money spent on each story, we will keep the voting fair. We suggest using this technique only once if you want clear and unbiased results.
Priority poker
This is a variation of planning poker played with prioritising in mind. The team and stakeholders are given a list of items to prioritize against a certain scale – this one may differ from 2 to 5 points or even more. So the deck of cards containing different amount of value points may look like this: 5 (very high priority), 4 (high priority), 3 (medium priority), 2 (low priority), 1 (very low priority). You may want to add another card – ? (insufficient information). The Scrum Master then reads a description of each user story and the participants privately attach value by placing one of the cards face down first. Then the cards are revealed simultaneously. There’s bound to be discrepancy in score. Therefore, it is followed by a discussion and a consensus on the importance of each story. Alternatively, you may form an aggregate score for each item. Repeat the procedure with all the Backlog items.
Two-step prioritization
Backlog prioritization is the Product Owner’s prerogative and as such primarily involves the client and stakeholders. They are better off at value estimation while the team can provide expert estimates of technical aspects. However, it can make sense, for the dev team to have a say, too. So after measuring value and effort, it’s good to have a common final discussion.
The techniques below may help to align business and IT needs.
Business Vs Effort approach
This approach is easier implemented with small-sized projects where we can relatively easily divide features into two oppositions: ‘important – unimportant’ and ‘simple – complex’.
The backlog is then seen as containing roughly four categories of items estimated against two axes – ‘business value’ (measured in value points) and ‘effort’ (measured in story points). Here’s a graphical representation of the idea:
The four quadrants show the items’ value and effort as high or low respectively. So which category shall we implement first?
As delivering business value early is a key to success, we would start with ‘high value, low effort’ stories. These are few and delivering them early allows us to receive early feedback. Some of them are bound to be ‘waste’ first time, so discarding of small bits of code will be less painful. Next, as we ramp up, it’s good to deliver ‘high value, high effort’ features. These will take up a lion’s share of time and effort, but they are crucial in bringing revenue. So businesses should have them sooner. With time, requirements will get honed and scaling these large stories will be easier while the risks of uncertainty will probably diminish. The features of ‘low value, low effort’ are just ‘nice-haves’ but don’t make much difference to business, so their implementation will depend on the budget remainder. The fourth quadrant items may not be delivered at all.
Banging-for-the-buck Score
In some projects a two-point level of prioritization is just not enough, so this technique may come in handy. Banging-for-the-buck (BFTB) Score shows a ratio of business value to the effort. After all backlog items have been estimated in value and story points by business and developer teams respectively, it’s possible to calculate the score.
The items will be prioritized against the value received.
However, there are cases when some low-value functionality has to be delivered first to ensure system viability: simply put, you cannot build a roof without building walls first. That’s why the participants will have to get together afterwards to refine the Backlog.
Nice prioritization techniques discussed above Olga. To make the prioritization process more easy, you can also make use of airfocus( https://airfocus.io/), which not only helps you with prioritization but also with product roadmapping, planning and a lot more.