Sprint ceremonies

During each sprint, our scrum teams (Ada, Grace, Katherine) hold regularly scheduled meetings to facilitate communication between members on the scrum team and across scrum teams.

Scrum team ceremonies

Individual scrum team ceremonies are attended by the full team assigned to that scrum team. These meetings are facilitated by the team’s scrum master and prioritization happens with the team’s product manager. How these meetings work is ultimately up to that scrum team.

Daily standup

Daily standups keep the team in sync. These regular touchpoints enable teams to identify opportunities for collaboration, surface blockers, and respond to changing circumstances. This is especially true in a virtual environment where team members need to be deliberate about staying in contact.

During a standup each team member answers the following questions:

What did you do yesterday?
What are you working on today?
Do you have anything that is blocking your work?

It is important that answers to these questions are kept brief. Anything that can’t be covered in a few minutes can be taken to a breakout in the time after standup.

Standups are open meetings and can be attended by anyone from Login.gov. It is important that attendees who don’t contribute directly to the team’s work remember they are attending standup as an observer. They should not interfere with the standup. Any issues they want to discuss should be addressed afterwards.

Sprint planning

Sprint planning is the first ceremony of a sprint. During planning the team reviews their sprint goal and plans the work they need to do to meet that goal.

Identify the sprint goal:

Planning starts with identifying the sprint goal. The product owner presents a goal for the sprint. The team works with the product owner to refine the goal if necessary.

Assess the stories in the sprint:

After a goal has been set, the team looks at the stories queued up for the sprint and asks themselves:

“Are these the correct stories to achieve our sprint goal?” If the stories in the sprint won’t enable the team to meet the sprint goal, the team should move the correct stories into the sprint.
“Is this amount of work achievable in a sprint?” The team should aim to complete all of the planned work in the 2 week sprint. If the team does not feel that is possible, then they should remove work from the sprint. This may mean working with the product owner to adjust the sprint goal to be achievable.

Planning for individual stories:

The bulk of sprint planning is spent looking at individual stories. The team goes through the stories and asks itself the following questions:

“Do we have what we need to complete this story this sprint?” If the team does not think a story is achievable, they may delay it for a sprint. They may also break it up and do the achievable component this sprint and the rest later.
“Is this story the right size?” If a story is not the right size the team can either break up during planning or schedule time early in the sprint to break it up.
“Does this story have the necessary acceptance criteria?” If ACs are missing or superfluous the team can adjust them.

Start the sprint:

After the stories have been reviewed, the team is ready to start the sprint.

Sprint review and retrospective

Sprint review is the final ceremony of the sprint. During sprint review the team looks back on the work they accomplished during the sprint. After reviewing the work from the previous sprint the team retrospects. They reflect on how they could be more effective and adjust the way they work accordingly.

Review the sprint board:

The first part of a sprint review is reviewing the sprint board. The team should make sure that the board reflects the work accomplished during the sprint.

The team should review the stories they completed and any stories that are still in progress. The team should ask whether the work they did this sprint meets the sprint goal they set during planning.

Review metrics:

A good scrum team measures the things they want to change. At the start of planning the team looks at the metrics they are measuring and how they have tracked over the past few sprints. Reviewing metrics gives team members an opportunity to determine if recent changes have been effective and whether they are headed in the right direction.

The metrics a team tracks are ultimately up to the team. However, every team should be tracking velocity, which is the number of stories delivered in a sprint. Velocity gives the team a rough measure of how much value they have delivered to users.

Identify what is and is not going well:

After reviewing the work done in the sprint the team should take some time to discuss what went well during the sprint and what could have gone better. The team should try to find underlying themes and root causes for issues that are brought up. The team should also brainstorm potential things they could change about how they work to prevent issues going forward.

Figure out what the team wants to change going forward:

After reflecting on what is and is not working, the team should identify one or two things they want to change about the way they work.

It is important that when the team is thinking about changes, they should focus on making changes that are achievable and measurable. The team should not feel like the must solve every problem right now. They should identify one or two impactful changes, commit to those, and determine how they will measure their success later.

Review whether changes the team made previously are working:

To enable the team to measure the impact of their changes and adjust, they should set aside some time to reflect on whether changes they made in the past are working. If something is working the team can decide to stop tracking it and make it part of their practice. If something isn’t working, the team can try to change their approach or just decide to stop doing that thing.

During each sprint, the team should spend time looking ahead and planning work for future sprints. Scrum team backlog refinement is an opportunity for the team to do this together.

The goal of this ceremony is to have a backlog that reflects the team’s future work and shared context about what stories in the backlog mean. At the end of refinement the stories in the next sprint should be ready, stories that need to be broken up have been identified, and the team has looked ahead at future sprints.

Product owner reviews the priorities:

To set context for the refining the backlog, the product owner starts things off by discussing the priorities. This is typically an at-most 5-minute review of the highest priority items for the next sprint and a quick review of where the team is on the roadmap.

Prioritize new stories or identify missing stories:

Scrum team members will open stories for future sprints throughout the current sprint. After reviewing the priorities there should be time to review new stories as a team, discuss them, and prioritize them in the backlog.

Frequently, the volume of new stories is too high for the team to review every single new story during refinement. If a story seems especially important or has some context that needs discussion, team members should make a note to bring it up during this part of refinement.

While prioritizing new stories, the team should discuss factors that may influence prioritization and advocate for a particular prioritization. The final prioritization of a ticket is left up to the product owner.

New stories that don’t get discussed during backlog refinement should be prioritized by the product owner outside of refinement.

Scrum team works through stories in the next sprint:

The bulk of backlog refinement is spent preparing stories in the next sprint. The scrum team should go through the stories and make sure they are ready for the next sprint.

When looking at stories, the team should make sure each story will have the necessary ACs and artifacts in time for sprint planning. The team should also identify stories that need to be broken up and either break them up in the meeting or schedule dedicated time to break them up later.

The team should be wary of getting bogged down on 1 or 2 stories during refinement. While refining stories, the team should make changes that can be made quickly. If stories need more work, the team should schedule time to work on them outside of refinement.