Sprint Backlog

• A prioritised list of work for the development team that is derived from the roadmap and its requirements.
• The most important items are shown at the top of the product backlog so the team knows what to deliver first.
• The backlog serves as the connection between the product owner and the development team. They are free to re-prioritise work in the backlog at any time due to customer feedback, refining estimates, and new requirements.

Tip

The team doesn’t work through the backlog at the Product Owner’s pace and the Product Owner is not pushing work to the development team. The team pulls work from the backlog as there is capacity for it either continually (Kanban) or by iteration (Scrum).

• Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items.
  • Near-term items need to be fully fleshed out before they are labelled as such.
    • This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made.
  • Longer-term items can remain a bit vague, though it’s a good idea to get a rough estimate from the development team to help prioritise them.

Anti-Patterns to Watch For

• The product owner prioritises the backlog at the start of the project (but does not adjust it as feedback rolls in from developers and stakeholders).
• The team limits items on the backlog to those that are customer-facing.