Sprint Plan for Development

---

Purpose

On larger projects with multiple moving parts, we’re finding that the excessive amount of meetings as currently implemented are often counter-productive for the software development team. We propose the following structure, which meets the goals in terms of the required ceremonies, but maximises the time available for each person to produce the required work. This proposed structure doesn’t mean that additional meetings can’t be scheduled, but it’s really important to allow the devs time to focus and not lose time with larger daily standups (for example) where the bulk of the discussion may not be relevant to the full team. Teams will still be able to communicate directly during the sprint, for example if art needs information on a technical aspect of their delivery, they shouldn’t wait until the next team-wide check-in to find that out.

Day 1 (Usually a Monday)

• Sprint planning
  • Devs to decide which features will be worked on via a quick sync call (early AM, 15 mins)
    • Rough allocation of stories/aspects to devs
    • Ideally this info should only be pulled from the existing project feature roadmap
    • PM and PO should be in this call too
  • Devs individually define stories, tasks and sub-tasks in a shared sheet (3-4 hours)
    • This includes considering complexities, time estimations, dependencies, etc
  • Detailed dev sprint planning call (early PM, 1 hour)
    • Discuss planned tasks
    • Devs motivate those tasks to the team and explain thinking for implementation
    • Other devs interrogate and provide feedback to approach and estimated time
    • PM and PO should be in this call too
  • Add tasks to GitHub Issues/Jira
• Start dev

Days 2-9

• Continued development of defined stories/tasks
• Regular PR's as tasks are completed
• Continuous discussion and review within the dev team, as required
• Asset integration
• Builds happen automatically
  • New features tested internally on builds throughout the sprint, not only in the Editor

Day 5/6 (Early PM if on a Friday, early AM if on a Monday)

• Mid-sprint team check-in (30-45 mins)
  • Full team, including dev, art, PM, etc
  • Check current overall progress
  • Discuss any potential pipeline issues
  • General confidence rating from each department on the current sprint

Day 10 (Usually a Friday)

• Named Build made and tested (early AM)
• Sprint Retrospective (early PM, 30-45 mins)
• Internal Sprint Demo (early PM, 30-45 mins)
  • Run through current state of the build, highlighting additions and known issues
• Deliver Named Build to direct client for additional feedback
• Deliver video recording of app for inclusion in client Sprint Demo presentation
• Dev clean up/documentation
• Devs prepare their slate for the next sprint

Daily Routines

• Standups to be done digitally
• Devs to post YTI’s (Yesterday/Today/Impediments) in the project Slack channel
• Ad-hoc calls/discussions between devs as needed to unblock each other
• Lead dev and PM can have a quick check-in via Slack to highlight any pressing issues

---