Prioritization is probably the most discussed part of development processes. Product backlogs are often quite complex with hundreds of requirements. How to find user stories in your story map which you should start developing first?
Traditional approach
The approach of traditional processes is simple. You have high, medium, low priorities. Ok, for some organizations it is still not enough so they have priorities on the scale of 0 to 10.
But do such priorities help deliver the most important and most valuable thing at the same time?
In agile, we want to support the pull principle. We want to let our developers pull the next requirement, develop it, deliver it. Then continue to the next one. So, in Agile we need a line of requirements. Agile processes and frameworks focus on the delivery of valuable stuff first. This is fine; however, there is a necessity to consider other perspectives as well. There are two kinds of companies.
If you want to prioritize and be agile, you can’t be just one of the types. You have to be company following both of them and even more.
Customers’ perspective
In ScrumDesk we prefer to consider the customer’s perspective first. The idea is that a satisfied customer is a driver of further changes and success of the product itself. A satisfied customer is willing to improve the product not just by social marketing, by new ideas, but in our case even by the development of the product itself.
As the product owner, the first thing you have to understand is who your customer/user is. You need to understand and describe her space, her context, her jobs, the pains or gains she is looking for.
The best part is just coming. Based on a more than 10 years old survey done by Scot Ambler, 45% of functionalities are NEVER, NOT ONCE, used. Only 7% are used always. Plus 13% very often.
So, why develop something that customers will not use? You just spent the life of your colleagues! Common! The answer is NO! Now MoSCoW prioritization comes to help.
Check the ScrumDesk Agile Toolbox
Based on that you should be able to decide if a feature is:
- Must – a heart is a “must”. Without it, there is no live organism. What is a must in your application?
- Should – a hand is “should”. Without it is hard. But you can survive even without a hand. Well, in most cases.
- Could – hair is “could”. It is fine to have them, you even look nicer, but you will definitely survive without them.
- Won’t – unnecessary waste. Btw, is there anything “won’t” in a body?
How to estimate MoSCoW values in 7 steps?
- As a Product Owner, try to be in the skin of your customer. There might be multiple types of them, so choose one, or some group of them.
- If you were him, will the feature be a must, should, could, or won’t?
- Forget about the time of development, forget about effort. It is just about customer and feature.
- What if this feature was not a must, but should? Would the customer realize that?
- What if the feature was could and not should? Would the customer realize that?
- Try to make it less “must”. Remember 7% features used always.
- Compare requirements to each other. Repeat a couple of times.
Let’s say your backlog looks like this:
After MoSCoW prioritization you should have a line of requirements ordered by MUST, SHOULD, COULD values. This might be done in ScrumDesk PLAN view
How to manage MoSCoW in ScrumDesk?
To set the value to backlog item you need just click it (in any view, either STORY MAP, BACKLOG, PLAN or WORK) to access details in the side view. Prioritization fields are displayed below the title of the backlog item. The first one is MoSCoW.
Value can be visible on cards in STORY MAP.
Once the value is entered, you can filter and group items based on it all ScrumDesk views, i.e. in the product backlog.
However, you are not done with prioritization in this step. What about business value?
