Let's start with Agile Manifesto, it says
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Where there is value in the items on the right, we value the items on the left more. Reason is simple Agile focuses on Kaizen (Continuous Improvement), which is a strategy where employees at all levels of a company work together proactively to achieve regular, incremental improvements in the product.
Backlog grooming or refinement is the process which focuses on Continuous Improvement on the product being developed.
What is product backlog refinement?
Product backlog refinement is the process through which product backlog items are reviewed by the Scrum team and revised, providing more detail and ensuring that there is greater clarity in the requirements for that item.
What product backlog items should be refined?
Any product backlog item should be refined as and when additional information is known about it. However, priority should be given to refining the product backlog items that are likely to be taken into the next sprint. This will ensure that enough information is known about each item to allow for it to be sized, for the plan to be generated during sprint planning as to how the selected product backlog item can be delivered, and to allow for the team to commit to delivering that and other items in the next sprint.
When should product backlog refinement take place?
Product backlog refinement should be an ongoing process. However, some teams find it useful to have a planned mid-sprint session that allows for product backlog items that are candidates for the next sprint to be discussed.
There are several ways to prioritize the requirements in the backlog. Some of the most popular ones include
1. MoSCoW
M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not affect anything else.
W - WON'T have this time but would like in the future.
S - SHOULD have this if at all possible.
C - COULD have this if it does not affect anything else.
W - WON'T have this time but would like in the future.
Each requirement will have the priority which would be tagged to MSCW. "M" being the highest and "W" being the lowest.
2. Business Value Based
In this case, each requirement carries a business value it could potentially generate to the company. The business value would be decided either by the Product Owner or the Product owner team.
The requirement with highest business value is implemented during earlier releases.
3. Technology Risk Based
In this method, requirements are prioritized based on the risk associated in implementing it. The risk is typically based on the technology.
The requirement with highest technology risk is implemented during the earlier iterations.
4. Kano Model
In this method, the requirements are prioritized based on the customer preferences. Mr. Noriaki Kano developed Kano model as valuable technique helping to recognize that. Applying this method the product owner can identify importance of stories by asking questions like these:
Is the feature mandatory? We will not earn additional revenue once we have it but without it the product doesn't fulfill existence principles.
Having a feature, will customer say: "Hey, that's nice! I like this approach and it seems to be really helpful." This feature is excitement. It is possible differentiator.
Well, guys improved a performance of the application. This is valuable. Comparing to other products, this product is one I would like to use.
Hmm, this feature is indifferent. It doesn't matter if this feature is or is not implemented. If vendor provides it, ok, I accept it. If it's not implemented, no problem then.
This feature is really questionable. I am not sure if I am going to pay for product with such feature. It'll probably slower me. Also, I assume it will complicate usability in my company. Let's think about different product.
Ohhh no! Not the feature like that. You are kidding. These features reverse me to really find a different product. Such perspective is great way to identify priorities in complex backlog.
- Attractive
- One-Dimensional
- One-Dimensional
- Must-Be
- Indifferent
- Reverse
5. Walking Skeleton
In this method, the requirements are selected such that minimal carefully selected end to end features are built within a short span of time.
6. Validated Learning
In this method, features are chosen based on the highest market risk i.e. something that is not experimented yet. Release it to the market, get the feedback and apply the learning onto the new feature
In this blog I covered basic definitions of Backlog Prioritization techniques , I would suggest please refer several blogs and eBooks available out there on internet for more details.
Please let me know you inputs, Suggestions or questions on this.
Courtesy: several online resources i.e. Blogs, Tutorials etc.