Sprint Planning - Daedalus Coaching

The Product Owner briefs the squad on their priorities for the upcoming Sprint, how these will increase the value of the product and for our customers, and how it aligns with the wider Product Goal.

From this, the Team defines and agrees to a provisional Sprint Goal. Find out more here.

Jointly select work items from the product backlog, choosing:

• Only from the refined items (that meet the Definition Of Ready, if used)

• The highest-priority items that best align with the sprint goal

• Only enough items so that you can maintain a high confidence of delivering ALL the selected items in full, within the Sprint

Beware:

Items with dependencies on each other in the same sprint: if one Work Item cannot be started until a preceding Work Item has been completed, it could cause bottlenecks to delivery. Try: identifying and eliminating dependencies as you split stories during refinement.

At this point, selected items are already refined, prioritised and estimated as part of the refinement process to meet an agreed Definition of Ready.

The work you do in the Sprint progresses items to meet the Definition of Done. Consider the following:

• Make sure everyone understands the Sprint Goal - and how the selected Product Backlog Items (PBIs) contribute to it.

• Prioritize PBIs based on the Sprint Goal, dependencies, and value delivery

• "What's the most important work to start with when we leave this event?" rather than trying to sequence everything upfront.

  • Break down PBIs into tasks to cover the first few days

  • Identify dependencies and potential bottlenecks and sequence the work accordingly

  • Don't overinvest in planning every little thing for the entire 2 weeks - it will have changed by the time you get there.

  • Avoid rigidly assigning tasks; instead, perhaps offer tentative ownership that allows for flexibility in task selection.

  • Take the time to do a Three Amigos session (e.g. developer, tester, product) when you pick up an item, to ensure you fully understand what needs doing and why

  • Allow for pair programming and mob programming opportunities

"Test early, test often" - integrate testing throughout the Sprint, rather than leaving it for the end. e.g. Define test cases alongside development tasks; involve testers in task breakdown discussions; and plan for incremental testing as features or components are completed.

Remember, the Sprint Backlog is a living artifact: You will re-evaluate and adjust it daily, during the Daily Scrum to better adapt to changes and insights gained as work progresses.

Aim to stick to the 2hr Planning timebox - to prevent over-planning. Manage this actively so you do at least exit planning with a coherent, realistic Sprint Backlog:

• Keep the discussion focused

• Don't get bogged down in excessive detail

• (Don't just stop wherever you are after 2 hours)

• Plan for Learning - surprises and learning opportunities are part of the process.

• Value adaptability and learning over strict adherence to a predetermined plan

MOST IMPORTANTLY: if this planning (part 3) indicates you've over-committed in part 2, change your forecast: perhaps, simply remove the lowest priority items (at the bottom of the forecast) until you collectively feel it is genuinely achievable.

• The Product Owner sets the direction, but not the pace

• Everyone contributes to agreeing on a meaningful Sprint Goal that helps you select a coherent set of PBIs to progress in that direction

• The Team determines a realistic forecast for the Sprint

• You are committing to deliver your Sprint Goal by producing an Increment comprising your selected PBIs

• Everyone is responsible for improving how you work to increase the flow of customer value

Aim to achieve "most of your forecast, most of the time"...

* if you always meet it, try being a little bolder, to find your true capability * If you rarely meet it, think about what's leading to that overcommitment: adjust downward AND work to increase that capability until you can adjust upward again