Sprint Planning Strategies

---

Purpose

This document contains various strategies, insights and methodologies to help developers and project managers with the sprint planning process.

🛣 Defining a Roadmap

• For a project with limited sprints, it's worth creating a feature roadmap
• Outline what the main features are for each sprint
• Set delivery goals/milestones up front
• This creates certainty in the initial/ideal order of development
• Helps to ensure the client is also aware of what will be delivered when
• Easier to see if you're overall ahead or behind
• Additional clarity on external resources required to fit into your schedule (e.g. art, UI, voice overs, etc) so that there is cross-departmental alignment

☑︎ Defining Tasks

• Break conceptual tasks into their respective implementation components
  • View
  • Logic
  • Model (e.g. database, CMS, etc)
  • Connecting code (e.g. GameManager, Controllers, etc)
• Rather over-scope than under-scope
• Tasks with a lot of uncertainty should be scoped as worst case
  • Bugs with unknown causes/no way to replicate
  • Tasks with unknown implementation details that require more research
  • Tasks that are very precise or require expert knowledge (e.g. complex math, shaders, text display)
• Task complexities are important
  • Some tasks are hard to do but quick, others are easy but need lots of time
  • Defining the complexities provides insight into your potential resolution (e.g. brute force or elegantly automated)

📝 Task Details

• Assume every task you create will be implemented by another dev
• Assume they will not have contact with you to ask questions
• Assume the person implementing has no institutional knowledge
• Assume you will forget the idea that you had regarding its implementation and need to leave a note for yourself
• Always provide more info than you think will be needed
• Leave clues as to what's easy, etc
• It's worth adding "the ideal outcome" to a task description, especially for complex tasks with multiple potential resolutions. If there is an outcome to refer back to, a dev will always have a reminder of what they're aiming for

⌛️ Task Priorities

• Always consider the hierarchy of tasks and related dependencies
• Priorities should be spread across the tasks
  • Not all tasks should be High, if so there is a deeper problem
  • Low priority tasks are ideal for deferment to another sprint if unforeseen issues arise that need remediation
• Ideally there would be one easy immediate task that starts a cascade of other tasks, which can be useful to get you into flow on a sprint

👩‍👧‍👦 Planning as a Team

• On most projects, a full day will be allocated in each sprint purely for sprint planning, some projects will have two full days for this
  • This planning time should be used in its entirety
  • More time spent planning and processing potential issues, will allow for more efficient development during the sprint
• All devs involved in the project should have a sync call first
  • Ensure there is alignment on the goals for the sprint
  • Understanding of the general technical approaches required/favoured in order to meet those goals
  • Discuss who will be taking on what responsibilities
  • If user stories already exist, discuss the following:
    • Allocations
    • Technical approaches
    • Potential issues
• Devs then individually create tasks/subtasks based on the initial discussion
  • Add details as outlined above
  • Leave guidance as to preferred strategy/potential avenues for exploration
  • Consider the overall complexities of each item
  • Allocate a time for each task/subtask
• Once all devs are done with their individual planning, the full team must reconvene to discuss all the tasks
  • Each dev needs to motivate the following to the team:
    • Technical approach to solving an issue
    • Implementation approach for adding a feature
    • Time estimates for each task/subtask
    • The reasons for these motivations are as follows:
      • Other devs may have had alternate ideas, some of which will be better, some worse, and it's worth having those conversations at the outset
      • Additional considerations that you may not have been aware of can be highlighted
      • Assumptions are largely removed and replaced with clarity - especially when dealing with multiple layers (eg front end, back end, database, etc)

---