Healthy Product Backlog: Customer immediately understands every item in the product backlog.

These are commonly useful good practices to get your product backlog in healthy state. Try these, your mileage may vary:

(1)  Customer goal oriented product backlog items. What outcome does your end-user desires?

• Avoid solution oriented backlog items. State – what goal needs to be accomplished, and collaborate with development team on discovering how the user can accomplish her goal.
• Avoid technical tasks in the Product Backlog. For technical upgrades within the product, ensure that the Product Owner understands new customer capability (value) enabled or risks averted.

(2)  After a large item is split, ensure that customer can complete some desirable goal with each new sub-item.

(3)   Just in time elaboration: Focus on maintaining sufficient detail and information for top-ordered product backlog items. Items that are lower in ordering stack, can be coarser and do not need details yet. Trust that the Product Owner and the development team will work through necessary details in planning and refinement (grooming) activities.

(4)  Set expiry date: Stale items that have been on the shelf for a long time and have never risen up in your ordering are most likely not needed. If they are truly needed, they will emerge again. Set an expiry date say – 2 months or 6 months for items in the product backlog. If these are not worked on for last six months, then its best to delete this item and rethink your customer’s goal within evolved business and product context.

(5)  Regularly prune product backlog items. Different from deleting, pruning involves elimination of decent ideas to allow room for excellent ideas to emerge through frequent sprint review feedback loops. A reasonably valid backlog item, that fails to connect emotionally with your customer or development team or your stakeholder is a great candidate to get pruned.

(6)  Limit number of product backlog items. If a scrum development team accomplishes five (5) items on average per sprint. Irrespective of the size of each item, it does not make sense to maintain a product backlog that has hundred (100) or more items. The team will never get to the 100^th item until the end of the year! Set an upper bound – say fifty (50) – and aggressively prune and group to maintain the count of product backlog items within its upper bounds.

(7)  Visual and tactile management of Product Backlog. Maintain your entire product backlog on a big wall near team area (If not the entire backlog, then about three (3) sprints worth). Out of sight is truly out of mind. Product backlogs hidden behind multiple clicks are hard to make sense of and harder to collaborate with. Why invite distributed team troubles when you are all co-located?

(8)  Metaphors and Models: A problem with reductionist approach towards Product Backlog is that we assume that all individual product backlog items, when added will somehow make a whole. Which is almost always never true.  Disparate backlog items don’t give designers context to work from. Enable your scrum team to develop shared context through frequent review of big picture and organization of items in higher-level metaphors and team generated models. These do not lend themselves to be itemized, but are extremely powerful in enabling a common vocabulary and triggering implicit needs. (Example: Shopping cart metaphor. There are many modeling techniques –Use Case Map, Mind Maps, Domain Map, Business Process Workflow  etc..)