Add an article describing scrum team ceremonies (#20)

This article only covers individual scrum team ceremonies. I plan to follow up with an update to add ceremonies that span teams.

_articles/sprint-ceremonies.md

@@ -0,0 +1,193 @@
+---
+title: Sprint ceremonies
+description: Overview of a scrum team's regularly scheduled meetings
+layout: article
+category: Product
+---
+
+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:
+
+1. What did you do yesterday?
+2. What are you working on today?
+3. 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.
+
+## Scrum team backlog refinement
+
+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.