Play: Sprint Planning

This Play is largely based on the common Agile practice of Sprint Planning. But as Atlassian says well, it’s got to have a few personal tweaks that make it right for our teams.

When to run the play

This happens at the start of each sprint cycle. Typically on day 1.

Why run the play

> To define the functionality of the epics planned in detail
> To align the team on the scope and size of each task
> To determine the priorities of the sprint
> To get a ‘Commitment’ (defined below) from each team member
> To ensure the team owns the execution, not 1 team member

Commitment:

If a team member ‘commits’ to getting a task done within the Sprint they should feel a sense of ownership and accountability for it. If for some reason the completion of a task is delayed and it needs to be moved into the subsequent Sprint, the team should work out why that happened, and agree on what to do to mitigate it in the next sprint. This can be done during the retrospective.

Hard Commitment:

In some cases, a ‘hard’ commitment might be needed to ensure we deliver, but this shouldn’t be often. A person should give a hard commitment to ensure this thing will be done, by the time they say it will be. A hard commitment transcends normal working hours and general practices. If a person is asked for a ‘hard’ commitment but isn’t comfortable with it, it’s a good thing, because it has raised a fragility in the Sprint, and should be addressed.

Rules

• Full squad, leave no soldier behind
• Take the time to listen to each other, and respect each others opinion
• Leave egos at the door, this is about the team and its output

Step 1 — Retrospective

(20 mins)

What Didn’t Go Well
Format: The producer asks the team to take 1 minute to write down what didn’t go well and needs improving. Then they share it with the team. Issues are resolved on the spot by the group, or if more complex then assigned to 1 person that wants to fix it.

Purpose: To resolve issues and pain points that reduce the time for creativity and craft

What Worked Well
Format: The producer asks the team to take 1 minute to write down what went well in the previous Sprint, then share it with the team. Team to then agree on what will ensure these things continue. Purpose: It’s a chance to celebrate our efforts, and note what is working that should continue

Purpose: To improve the way we are working together and to give people the opportunity to raise issues if they see them. It also enables us to be open about our mistakes, and ensure we learn from them. We want to create a culture of trust!

Step 2 — Review Sprint Milestones

(10 mins)

As part of the Planning Production Play, teams will have created sprint milestones and epics of work within them. Remind the team of the milestones and epics that were planned, and check that they don’t need to be updated.

Example of Production Planning Board:

Step 3 — Break Features Into Tasks + Estimates

(2 hours including a break)

1. Create a Kanban board using the columns Backlog, To Do, In Progress, PR Review, Done
2. Ensure the team are aligned on roles and responsibilities e.g. is the tech lead coding or not?
3. Break each epic into individual tasks of roughly 1 day or less
4. Add in a checklist of smaller items of each task to ensure that everyone is aligned on what the task includes
5. Add a definition of done for all development tasks
6. Assign the task to a team member — this could be a designer, developer or producer
7. The team member who is assigned estimates the task. This is important as the person doing the work should be the one who is responsible and accountable.
   Small = 0–30mins
   Medium = 30mins — 4 hours
   Large = 0.5 day — 1 day
   XL = Needs Further Investigation
8. Estimations are to be done as loose guides, not hard limits
9. Plan in roughly 4.5 days of work per week per person to allow time for meetings
10. Once the Sprint is planned then we sense to check that the amount of work seems reasonable to the people doing it
11. Last but not least, surface any meetings that are required to happen to do the work. For example, if you have XL sized tasks you may need to do a scoping session to work them out
12. Revisit goal or goals for the Sprint (for our studio as well as the client project) and make sure it’s still accurate to what you’re doing