The Book in Three Sentences
- Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products.
- A scrum team typically consists of around seven people who work together, in short, sustainable bursts of activity called sprints, with plenty of time for review and reflection built in
- Scrum recognizes only three distinct roles: product owner, scrum master, and team member
The Five Big Ideas
- The product owner is responsible for maximizing the return the business gets on this investment (ROI)
- In scrum, no-one but the product owner is authorized to ask the team to do work or to change the order of backlog items
- The product owner is responsible for recording the requirements, often in the form of user stories and adding them to the product backlog
- The scrum master acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance
- The team members doing the work have total authority over how the work gets done
Scrum Summary
An example of a story: “As a <role>, I want <a feature>, so that I can <accomplish something>”.
The product owner role in a nutshell:
- Holds the vision for the product represents the interests of the business
- Represents the customers
- Owns the product backlog
- Orders (prioritizes) the items in the product backlog
- Creates acceptance criteria for the backlog items
- Is available to answer team members’ questions
The scrum master role in a nutshell:
- Scrum expert and advisor coach impediment bulldozer facilitator
- People who do the work are the highest authorities on how best to do it.
If the business needs schedule estimates, it is the team members who should create these estimates.
The role of each and every team member is to help the team deliver potentially shippable product in each sprint.
What we are describing with scrum is a mindset change from “doing my job” to “doing the job.”
The team member role in a nutshell:
- Responsible for completing user stories to incrementally increase the value of the product
- Self-organizes to get all of the necessary work done
- Creates and owns the estimates owns the “ how to do the work” decisions
- Avoids siloed “not my job” thinking
The common rule of thumb, regarding how many team members should a scrum team have, is seven, plus or minus two. That is, from five to nine. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.
Scrum artifacts are the tools we scrum practitioners use to make our process visible.
The product backlog is the cumulative list of desired deliverables for the product.
While backlog item is technically correct, many scrum teams prefer the term “user story,” as it reminds us that we build products to satisfy our users’ needs.
The list of user stories is ordered such that the most important story, the one that the team should do next, is at the top of the list.
Since stories near the top of the product backlog will be worked on soon, they should be small and well understood by the whole team. Stories further down in the list can be larger and less well understood, as it will be some time before the team works on them.
Each item, or story, in the product backlog should include the following information: Which users the story will benefit (who it is for) A brief description of the desired functionality (what needs to be built) The reason that this story is valuable (why we should do it) An estimate as to how much work the story requires to implement Acceptance criteria that will help us know when it has been implemented correctly.
The sprint backlog is the team’s to-do list for the sprint.
Unlike the product backlog, it has a finite lifespan: the length of the current sprint.
A burn chart shows us the relationship between time and scope. Time is on the horizontal X-axis and scope is on the vertical Y-axis. A burn-up chart shows us how much scope the team has got done over a period of time.
The simplest task board consists of three columns: to do, doing and done.
In order to avoid confusion, good scrum teams create their own definition of the word “done” when it is applied to a user story.
The sprint cycle consists of several meetings, often called ceremonies: sprint planning daily scrum story time sprint review retrospective.
Whether you call your development period a sprint, a cycle or an iteration, you are talking about exactly the same thing: a fixed period of time within which you bite off small bits of your project and finish them before returning to bite off a few more.
There are two separate decisions to take:
- Is the product potentially shippable? That is to say, is the quality high enough that the business could ship it?
- Are all of the current stories done? This is a decision for the team. Does it make business sense to ship what we have at this time? Is there enough incremental value present to take the current product to market? This is a decision for the business.
Sprint planning marks the beginning of the sprint. Commonly, this meeting has two parts. The goal of the first part is for the team to commit to a set of deliverables for the sprint. During the second part of the meeting, the team identifies the tasks that must be completed in order to deliver the agreed upon user stories. We recommend one to two hours of sprint planning per week of development.
The goal of part one of the sprint planning meeting is to emerge with a set of “committed” stories that the whole team believes they can deliver by the end of the sprint.
Note the separation in authority: the product owner decides which stories will be considered, but the team members doing the actual work are the ones who decide how much work they can take on.
In phase two of the sprint planning meeting, the team rolls up its sleeves and begins to decompose the selected stories into tasks.
The output of the sprint planning meeting is the sprint backlog, the list of all the committed stories, with their associated tasks.
The daily scrum should always be held to no more than 15 minutes.
In a daily scrum meeting, each participant answers the following:
- What tasks I’ve completed since the last daily scrum?
- What tasks do I expect to complete by the next daily scrum?
- What obstacles are slowing me down?
Each user story in the product backlog should include a list of acceptance criteria. These are pass/fail testable conditions that help us know when then the story is implemented as intended.
Stories at the top of the product backlog need to be small. Small stories are easier for everyone to understand, and easier for the team to complete in a short period of time. Stories further down in the product backlog can be larger and less well defined. This implies that we need to break the big stories into smaller stories as they make their way up the list.
The retrospective, held at the very end of each and every sprint, is dedicated time for the team to focus on what was learned during the sprint, and how that learning can be applied to make some improvement.
Sims recommends one to two hours of retrospective time for each week of development.
Unlike the traditional “post mortem,” the aim of a retrospective is never to generate a long laundry list of things that went well and things that went wrong but to identify no more than one or two strategic changes to make in the next sprint.
Recommended Reading
If you like Scrum, you may also enjoy the following books: