Sprint Backlog

• The Sprint Goal (why), the PBIs selected for the Sprint (what), plus the plan for delivering them (how)
• Only the Development Team can change its SB during a Sprint, which belongs solely to the Development Team
• Myth: The Sprint Backlog is a Commitment of functionality
  • it is a commitment to do their best to achieve the SG
• Sprint Backlog is NOT FIXED during the Spring
  • Myth: The Sprint Backlog can’t change during the Sprint: The Development Team commits itself to implementing all the items on the SB. Changes are not allowed during the Sprint; no work can be added or removed
    • we can't create detailed plans for the future. Even if that future is a single Sprint, new insights or impediments may emerge
    • as more is learned, the Development Team will then re-negotiate the Sprint Backlog with the PO
    • Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal
    • SB is not a fixed list of work to be done: living plan by the Development Team on how it will meet the Sprint Goal. It needs to be flexible: Sprint Goal is the true aim of the Sprint
• The Sprint Backlog is
  • … the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.
  • … a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment
  • … is a forecast of the work needed to achieve the goal
  • … makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal
  • … is a plan with enough detail that changes in progress can be understood in the Daily Scrum
  • is the “smallest possible time-box for a Scrum Team to deliver a coherent set of valuable features without losing focus”. Instead, Sprints are often understood merely as arbitrary containers to “fill with work”
• SB EMERGES during the Sprint as they learn more about the work needed
  • Examples:
    • As new work is required, the Development Team adds it to the Sprint Backlog
    • As work is performed or completed, the estimated remaining work is updated
    • When elements of the plan are deemed unnecessary, they are removed
    • a technology they picked does not perform as expected
    • a key feature needed to reach the Sprint Goal was missed during the Sprint Planning
    • last minute request
    • important bug
  • Embrace the emerging nature of the Sprint Backlog: Encourage the Development Team to change, modify and improve the Sprint Backlog during the Sprint
  • It’s up to the Development Team to apply these changes and inform the Product Owner if this is considered necessary
  • Any changes done to the Sprint Backlog are done with achieving the Sprint Goal in mind and building a “Done” Increment
• Forecast VS Commitment
  • FORECAST: about the functionality that will be part of the next Increment and the work needed to deliver that functionality into a “Done” Increment
  • COMMITMENT (see DT role)
• Characteristics
  • by and for the Developers
  • highly visible, real-time picture of the work they plan to do during the Sprint in order to achieve the Sprint Goal
  • updated throughout the Sprint as more is learned
  • should have enough detail that they can inspect their progress in the Daily Scrum
• Content
  • WHY: Sprint Goal
  • WHAT: A set of PBIs that form a plan to realize the Sprint Goal: A forecast of functionality in the next increment
  • HOW: A forecast of the work required
  • highly visible, real-time picture, living plan, and transparent artefact to make visible all the work the Development Team has identified as necessary to meet the Sprint Goal
    • The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog EMERGES during the Sprint as they learn more about the work needed
• Sprint Goal (Purpose) – Commitment of the SB – measurable - desired outcome – why
• SBI (Scope) – expected output - what
• Tasks (Plan) – how
  • Discussing the "how" helps identify dependencies, gaps in skill/knowledge, and other impediments
  • This can include the preparation of the Sprint Review
• Models:
  • Example Scrum Task Board 1 (PB divided in tasks)
    • PB, SB, In Progress, Peer Review, In Test, Done, Blocked