Why you should treat Product Backlog as LIABILITY not an ASSET and what you can do to make it good LIABILITY.
This post mainly for Product Owner but others can also benefit.
Every change to any system (especially Software) is expensive, time consuming and many a times mysterious (there are zillions ways a new change can impact the system in bad ways).
Although we all get paid because we are responsible for making changes or creating new things but as a Product Owner we should treat every Product Backlog Item as a LIABILITY, and like we do(should do) in our real life we should not have too many bad liability.
This means that every change that is going to be part of our new sprint should pass the test of ‘murdered meeting’, in this meeting we should ask tough questions to ‘murder’ the requested change , so that only those changes which pass ‘Murder meeting’ are eligible for next sprint.
Your backlog may contains all such features (sometime to please wishful customers, your CEO, if it’s internal product, and other stakeholders) but not your next Sprint.
‘Art of Murdering’ any feature or change request comes from previous useless features that you as a product owner have implemented, only to find that nobody uses that, plus you can do a small survey along with murder meeting.
Point here is to justify the selection of the features or change based on simple statement that why should we choose this feature over this and whether it does align with our strategic goal of the company.
If you have watched a very good movie you will find that every scene in the movie has a purpose, it adds value to the overall message in the movie, and similarly every feature should add some value to the overall objective of the product, adding more features (or more scenes) will not make product (or movie) success but what have to be done and what have to be left out, will decide the success.
Conclusion: Get ready to say ‘NO’ or (Kill) features and try to reduce your liability list.
- Less features
- Less options/preferences
- Less people and corporate structure
- Less meetings and abstractions
- Less promises