Is Your Backlog Up To CODE?
The product backlog is the central artifact for a Scrum team. It defines the value to be delivered to customers; it keeps the team focused with clarity and priority; it shows stakeholders what they can expect. If you want a high-quality product and an effective team, then you must have a well-formed Product Backlog.
The acronym CODE defines the four characteristics of a strong product backlog: Comprehensive; Ordered; Detailed appropriately; Evolving.
Comprehensive
According to the Scrum Guide, the Product Backlog is the single source of work undertaken by the Scrum team. The backlog contains ALL types of work done by the team: new features, maintenance tasks, defect fixes, even action items for process improvement. It includes all the known work required to achieve our next milestone, which is typically a 3-4 month timeframe. It provides transparency for the team and stakeholders, so we diligently avoid invisible work — all the work is made visible in the backlog.
Ordered
Product Backlog items are strictly ordered or sequenced, not just prioritized. The Product Owner is accountable for ordering, and collaborates with stakeholders and the team to determine the optimal ordering. Many factors go into ordering: ROI, urgency (cost of delay), dependencies, and risk mitigation.
Detailed appropriately
Items for the next 1-2 sprints should be small, detailed, and well-understood: in other words, ready to be started by the team. Items farther into the future may be larger and less detailed. The Product Owner is accountable for refining those items into smaller and more detailed items just-in-time, in collaboration with stakeholders and the team.
Evolving
The Scrum guide describes the product backlog as emergent, meaning that it evolves over time. With each Sprint, we get feedback from stakeholders and the team gains more knowledge; this new information helps us to make the backlog better.
Some practical tips for managing your product backlog:
Use labels, tags, or different item types to differentiate features (user stories), defect fixes, maintenance/tech debt, and process improvement items.
Limit the length of your active backlog to ~100 items. Create a separate ‘future backlog’ for any items beyond this limit.
Product Owners: block time on your calendar prior to team refinement meetings to get the backlog into good shape.
Product Owners: don’t shoulder all the burden of backlog refinement. Engage your stakeholders and team to contribute directly.
Give your stakeholders a template for submitting new backlog items; expect them to provide a sufficient amount of preliminary information, then have a conversation with them to refine the details.
Make the backlog visible to stakeholders. Review it with stakeholders each Sprint, e.g. at the Sprint Review meeting.
Set an expiration date for stale items: if an item has been in the backlog for more than 6 months, delete it (or archive it, if you’re a hoarder)
To achieve a high-quality CODE backlog, teams need strong Product Ownership, consistent stakeholder engagement, and team contribution. The backlog refinement process is how the magic happens, which we’ll address in a future post.