Good Product Owners Delete Product Backlog Items

Good Product Owners Delete Product Backlog Items

At a recent course, one of my attendees talked about his use of a "to delete" status for items in his Product Backlog. Where items had been in his Product Backlog for more than 3 months he tagged them as "to delete". He would then review this sub list with stakeholders as part of the ongoing Product Backlog Refinement process. After some discussion the items were either deleted/archived or the tag was removed.

With new Product Backlog Items (PBI's) being added all the time, he wanted to encourage his stakeholders to remove PBI's if they had been around for awhile but had never been deemed valuable enough to work on. It was likely these would never be implemented as there would always be something more important to do. This reminded me of an important point - Good Product Owners Deleted Product Backlog Items.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:....Ensuring that the Product Backlog is visible, transparent, and clear to all - The Scrum Guide

In many organisations, the rate of new Product Backlog Items being generated far exceeds the Development Team's capacity to convert them into increments of working software. As a Product Backlog grows over time, so does the time required to refine it. Much time can be spent discussing this huge number of PBI's. Time is money, and as many of these PBI's will never be implemented this introduces significant waste into the Product development process.

As part of Product Backlog Refinement, good Product Owners will proactively aim to keep the Product Backlog as small (in terms of numbers of features) as is possible to reduce this waste. Even if not deleted, items should be archived to remove them from the Product Backlog. This will help eliminate waste and allow more time to be spent focussing on the features that will be implemented. Focus is a Scrum value and this technique is one way Product Owners can bring greater focus to the Product Backlog.

Read more at www.thescrummaster.co.uk/blog

?ndra Rininsland

Creative Technologist

8 年

What Steven said. I think I'm going to mercilessly apply this to the ~500 open issues in the C3.js GitHub queue...

The same should apply to open bug reports that have been left to gather dust. If you're never going to realistically fix them, get them closed off.

Amanda Dahl

Deputy Director @ Government Digital Service | Digital Transformation, AI Ethics, Women in Tech | Alumni: BBC, PlayStation, US Digital Service

8 年

A thousand times yes. Dump the junk! It will only serve to frustrate and confuse.

Benjamin d'Eusanio ????

Coach Organisation, Equipe, Individuel, Lean&Agile - Coach Professionnel

8 年

Recently, during a kick-off I tell to my extended team the quotation of Antoine de Saint Exupery: "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away." The PO must have the courage to delete PBIs. Adding more and more PBI do not mean that you'll have more, but you should. The backlog refinement is an opportunity to go deep on specific PBI in order to give the backlog transparent to all. This is also the opportunity to take the decision to remove the PBI if it is not relevant.

Kevin J. Halbleib, PSMII, PSPO, ITIL

Sr Director | Enterprise?Architect | ServiceNow Platform Owner

8 年

Personally, when acting as a Product Owner, I like to keep a list of everything - my "wish list". But I rank and sub-rank all of that so that the real dreamy content stays off the radar. I'd rank starting with a "1" for those PBIs that had serious consideration for a sprint within a few months, and then a "2" for outside contenders, and then a "3" or unranked for very long term or just flat out crazy ideas. Within my 1's, I'd then sub-rank again, and generally I'd sub-rank the sub-ranked ones at least one more time. As a Product Owner your job is to optimize value. It helps to get it all down on "paper", and then visualize it. As a Product Owner, no one (hopefully) tells you how to do your job. There must be a formal product backlog (transparency artifact), but nothing says the PO cannot have informal lists they use to do their job. And yes, periodically, I would purge my wish lists and the product backlog!

要查看或添加评论,请登录

Simon Kneafsey的更多文章

社区洞察

其他会员也浏览了