A Breathtakingly Brief Summary of Scrum

This a breathtakingly brief summary of Scrum: A Breathtakingly Brief and Agile Introduction by Chris Sims & Hillary Louise Johnson.

Definition

• Scrum is a simple framework for small teams to develop complex products.
• The principle of scrum is inspect and adapt, or continuous improvement.
• A scrum team consists of 5–9 people.
• A scrum team moves in short cycles of time called sprints.

Experience is the best teacher, and the scrum cycle is designed to provide you with multiple opportunities to receive feedback—from customers, from the team, from the market—and to learn from it.

Roles

Product Owner

• Represents the interests of the business and customers.
• Has a hold on the product vision.
• Directs the team towards the most important work.
• Prioritizes, orders, and discusses product backlog requirements and criteria with the team.
• Responsible for creating user stories to capture requirements, in the form of “As a <role>, I want <a feature>, so that I can <accomplish something>“.

Scrum Master

• Advisor to the product owner and team.
• Focuses on improving the team in order to increase the deliverables.
• Not a boss but a helper and scrum expert.

Team Member

• Has technical or domain skills required to create or contribute to a product.
• Has authority to decide how the work should be done.
• Creates estimates on items, user stories, tasks, etc.
• Helps the team deliver value each sprint.

Artifacts

Product Backlog

• Contains a list of product deliverables that represent:
  • Features
  • Bug Fixes
  • Documentation
  • Meaningful or Valuable Things
• Deliverables are known as items, and captured in the form of user stories.
• The user stories are ordered from most to least important in the backlog.
• User stories at the top should be well understood while user stories at the bottom can be revisited in the future for refinement or grooming.
• Good user stories should answer the following questions:
  1. Who is it for?
  2. What needs to be built?
  3. Why should we do it?
  4. How long will it take?
  5. What are the acceptance criteria?

Sprint Backlog

• Contains a list of sprint deliverables.
• The items in the sprint backlog have a limited timespan: the length of the sprint.
• Represents the commitment of the team to produce deliverables.
• User stories are broken down into tasks, or bits of work required to complete a story.
• User stories are units of value while tasks are units of work.

Burn Charts

• A chart for visualizing the relationship between time and scope.
• Time is plotted on the X-axis (horizontal) while scope is on the Y-axis (vertical).
• Tracks how much work a team has completed over time.
• The scope of the work can be measured in points and the unit of time can be measured in sprints.
• The chart moves upward when new work is introduced, and downward as the work is completed.

Task Board

• A tool for visualizing work for team members and stakeholders.
• The simplest task board consists of three columns:
  1. To Do
  2. Doing
  3. Done
• Tasks move across columns, giving the team visibility on their situation and allowing them to inspect and adapt.

Definition of Done

• Different members of the team might have different meanings for what “done” means.
• Good scrum teams create their own definition of “done”.
• The list of things the team does before declaring a user story as done becomes their definition.

The Sprint Cycle

The sprint cycle is the essential rhythm of scrum. It’s the period of time where work gets done, continually. It consists of five team meetings that fuel the inspect-and-adapt cycle of scrum.

The cycle can be as short as one week or as long as one month or more.

Sprint Planning

Duration: one to two hours.

• The beginning of the sprint.
• The planning is divided into two parts:
  1. What will we do?
     • The team settles on a set of user stories that it can deliver by the end of the sprint: the sprint backlog.
     • The product owner presents the user stories to the team for discussion, review, and acceptance into the sprint.
     • The product owner decides which user stories will be considered; the team members decide how much work they can perform during the sprint.
  2. How will we do it?
     • The team breaks down the accepted user stories into tasks.
     • The team can adjust the number of user stories at this stage if the work becomes too large for the sprint.
     • The product owner provides guidance, support, and answers questions until the stories become clear and broken down into tasks.

Daily Scrum

Duration: less than fifteen minutes.

• Usually called the stand-up meeting, as members physically stand up for the meeting.
• It is conducted daily, typically at the start of the work day.
• It is brief and to the point.
• Team members share the following:
  1. What tasks I’ve completed since the last daily scrum.
  2. What tasks I expect to complete by the next daily scrum.
  3. What obstacles are slowing me down.
• The goal of the meeting is for the team to inspect and adapt its own work in order to deliver the stories at the end of the sprint.
• Issues or problems that surface during the meeting don’t need to be solved during the meeting, they can be addressed afterwards.

Story Time

Duration: one to two hours, every week.

• A time for discussing and improving the user stories in the product backlog for future sprints.
• Also known as refinement or grooming.
• The team works together to answer the questions for writing good user stories, focusing on defining the acceptance criteria.
• During this meeting the team will size or estimate the user stories. These can be points or other metrics preferred by the team.

Sprint Review

Duration: one-half to one hour for every week of development.

• The end of the sprint.
• The team shows off its accomplishments and highlights the stories that are considered done.
• Stakeholders can be invited to the meeting.
• Feedback is gathered from the team and stakeholders.

Retrospective

Duration: one to two hours for every week of development.

• Time for the team to reflect on what was learned during the sprint and opportunities for improvement.
• It’s not about finding what went well or wrong, but about making strategic changes for the next sprint.
• The meeting should be focused on improving the process.
• The retrospective should be conducted in cases of abnormal sprint termination.

In scrum, the basic agreement between management and the team is that management won’t change up requirements during a sprint.