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.
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.
You might be interested in the following Scrum articles:
Product Owner Checklist for the Sprint Planning
What should you prepare as a Product Owner for the Sprint Planning? The most important is: 1. big picture 2. ordered…
How Sprint Goals help your Scrum Team deliver more customer value?
Learn why Sprint goal enables the Scrum Teams to achieve more
How to get started with Jira User Stories
Learn how to use Jira issues: Jira User Stories, Jira tasks, and Jira sub-tasks
How to involve your users in the Sprint Review?
Sharing my experience as an Enterprise Agile Coach and Product Owner: build first the functionalities they need most —…
Product Owner’s Checklist for Sprint Review
The PO must prepare for the Sprint Review Meeting? 1. Review sprint goals 2. Prepare the demo: dry run, data, collect…
12 Things you Must Know About the Sprint Review
#1. What is the purpose of the Sprint Review?
The Product Owner’s Vital Role in the Retrospective
In Agile, there are specific moments for planning, reviewing, and improving the entire scrum team. Product Owner, Scrum…
How to Write User Stories that Deliver Value to the Customer
Before we discuss user stories, let’s clarify what user stories are?
Why Velocity Works Better than Man Days Effort Estimation?
What is the velocity metric?
Nine user story metrics I care about while coaching Scrum teams
Goal: put in numbers the team performance. Numbers talk to everyone. When we see 98% performance there is no…
Hamburger Method to Split User Stories from Dev team perspective
The main reason why I use the Hamburger Method to split user stories is to coach the teams to transit from the…
How to Split User Stories
When it comes to defining user stories, I always give the cake examples to the teams I work it.
How and why the personas must be the starting point of our user stories to build better products
This week I started a new project — CooLab. We need to create an application which helps cooks to reach more people…