A quick guide of Remote Scrum Ceremonies
Remote Sprint Planning 101
Learn how to perform a Remote Sprint Planning Meeting, how to calculate team capacity, measure velocity, define spring goals, and select the Sprint backlog from the Product Backlog.
Why do we do sprint planning?
In Agile, we have moments of planning, executing, reflecting. The goal of sprint planning is to define and to commit to what will be built in the next sprint.
Who participates at the Sprint Planning?
The entire Scrum Team: including product owner, scrum master, and multi-disciplinary team. The Scrum master facilitates the planning meeting.
What tools to use when you do the Remote Sprint Planning?
- Video conference tool. You have a wide choice between Skype, Zoom, Google hangouts, teams. Zoom is, by far, my favorite because of the low bandwidth that it needs.
- A good microphone
- The project management tool you are usually using: TFS, Jira, Monday, any tool. I highly encourage you to do not to use any other tool because we want to minimize the administrative work and favor the delivery of business value.
Nothing more.
What is the agenda of sprint planning?
1. Define team capacity. The scrum master calculates it from the story points done in the last 3–4 sprints — the days off.
For example, in the last 3–4 sprints, your team made 30 story points with the full team working full time. But this sprint, one person from your team is taking 2 days off. How do you calculate your story points capacity for the next sprint?
In a 2 weeks sprint, the team dedicates about 1 day for scrum ceremonies (planning, refinement, stand-ups, review, and retrospective) and 9 days to user stories development. For the math's simplicity, we will consider that one team member is taking 2 days off on 2 days when the team has only the daily stand-up.
That means that for a team of 5 people, in normal conditions, you will have 5 * 9 = 45 working days in your sprint. But because a person takes 2 days off, you have 43 days. 43/45 = 96% availability. From a story point perspective, that means we have 96% of 30 Story points = 28.5 story points capacity for your team.
2. Clarify and estimate the Stories for the Iteration. Your user stories should be estimated during the refinement sessions and never after creating the tasks. The simple reason is that we use the abstract notion of story points to foresee the longterm. If we assign the story points after we create the tasks or during the sprint planning, the team’s knowledge level is very high. It means we are accurate only with a high level of information. Still, we want to estimate the backlog without necessarily investing a huge amount of time in detailing the user stories. And at the same time, keep the agility.
3. Break Stories into tasks (optional). Breaking user stories into tasks helps the team think about implementing the user story and a reference point after the sprint when things didn’t go as they planned. I recommend this activity to all the teams that I work with at the beginning of the collaboration. If, after half a year, we see that the team is predictable, mature, everything goes smoothly, we can eliminate this step from the sprint planning.
4. Load user stories into the sprint until there is no more capacity.
5. Define the sprint goals. The goals are an aim that the team helps to achieve by the end of the sprint. We have sprint goals because they give the team the flexibility to adjust the user stories to meet the objectives.
6. Commit as a team. The story points are tools that the Scrum team can use to understand how much they can commit to doing in a sprint. But the team commitment is needed for the teams to be able to give the best.
What should be the structure of the backlog?
Before your product is in construction, your backlog's composition is mainly user stories that develop new user functionalities. The moment the application is in production, a healthy backlog is made of user stories, refactors, maintenance, and spikes.
How long should the sprint planning last?
The benchmark of the duration of the sprint planning is between 2–4 hours.
True & False
Once the sprint started, we cannot add new user stories or change user stories. It is important to keep consistency during the sprint. You can use a lot of tools in agile that helps to bring clarity for at least the current sprint: spikes, refinement, enablers. But sometimes new user stories can appear, or sometimes the team might find a better or simpler way of implementing the same functionality. Now is the moment when the sprint goals are useful. The team's target is to achieve the team goals, not to respect all the specifications. The scrum team’s priority is to provide business value. You can adjust your user stories to reach the sprint scope. But, at the same time, this should be an exception rather than the rule.
We are agile, so we need to cope with changes that come during the sprint. Indeed, we need to be agile to adapt. But we also have to balance the cost of adjusting and changing directions versus the development benefits. Having precise moments of planning, reviewing, retrospective builds structure and makes the scrum team efficient.
