SCRUM: A Breathtakingly Brief and Agile Introduction
Chris Sims & Hillary Louise Johnson
What is SCRUM?
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. One of the mantras of scrum is “inspect and adapt,” and scrum teams are characterized by an intense focus on continuous improvement—of their process, but also of the product.
Scrum recognizes only three distinct roles: product owner, scrum master, and team member:
The product owner is responsible for maximizing the return the business gets on this investment (ROI).
One way that the product owner maximizes ROI is by directing the team toward the most valuable work, and away from less valuable work. That is, the product owner controls the order, sometimes called priority, of items in the team’s backlog. 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.
Another way that the product owner maximizes the value realized from the team’s efforts is to make sure the team fully understands the requirements. If the team fully understands the requirements, then they will build the right thing, and not waste time building the wrong thing. The product owner is responsible for recording the requirements, often in the form of user stories (eg, “As a <role>, I want <a feature>, so that I can <accomplish something>”) and adding them to the product backlog. Each of these users stories, when completed, will incrementally increase in the value of the product. For this reason, we often say that each time a user story is done we have a new product increment.
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 acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance. While a team’s deliverable is the product, a scrum master’s deliverable is a high-performing, self-organizing team.
The scrum master is the team’s good shepherd, its champion, and guardian, facilitator, and scrum expert. The scrum master helps the team learn and apply scrum and related agile practices to the team’s best advantage. The scrum master is constantly available to the team to help them remove any impediments or road-blocks that are keeping them from doing their work. The scrum master is not—we repeat, not—the team’s boss. This is a peer position on the team, set apart by knowledge and responsibilities not rank.
The scrum master role in a Nutshell:
- scrum expert and advisor
- impediment bulldozer
High-performing scrum teams are highly collaborative; they are also self-organizing. The team members doing the work have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks. The theory is that the people who do the work are the highest authorities on how best to do it. Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.
A scrum team should possess all of the skills required to create a potentially shippable product. Most often, this means we will have a team of specialists, each with their own skills to contribute to the team’s success. However, on a scrum team, each team member’s role is not to simply contribute in their special area. The role of each and every team member is to help the team deliver potentially shippable product in each sprint. Often, the best way for a team member to do this is by contributing work in their area of specialty. Other times, however, the team will need them to work outside their area of specialty in order to best move backlog items (aka user stories) from “in progress” to “done.” What we are describing is a mindset change from “doing my job” to “doing the job.” It is also a change in focus from “what we are doing” (work) to what is getting done (results).
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
So, how many team members should a scrum team have? The common rule of thumb 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.
These are the tools we scrum practitioners use to make our process visible.
The Product Backlog
The product backlog is the cumulative list of desired deliverables for the product. This includes features, bug fixes, documentation changes, and anything else that might be meaningful and valuable to produce. Generically, they are all referred to as “backlog items.” 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. Right below it is the story that the team should do second, and so on. 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
The sprint backlog is the team’s to do list for the sprint. Unlike the product backlog, it has a finite life-span: the length of the current sprint. It includes: all the stories that the team has committed to delivering this sprint and their associated tasks. Stories are deliverables, and can be thought of as units of value. Tasks are things that must be done, in order to deliver the stories, and so tasks can be thought of as units of work. A story is something a team delivers; a task is a bit of work that a person does. Each story will normally require many tasks.
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.
A burn down chart shows us what is left to do. In general, we expect the work remaining to go down over time as the team gets things done.
These events appear as vertical lines on the burn down chart: a vertical line up when we add new work, or down when we remove some work from the plan.
When the team’s tasks are visible to everyone from across the room, you never have to worry that some important piece of work will be forgotten.
The simplest task board consists of three columns: to do, doing and done.
Definition of Done
The team’s definition may include things like: code written, code reviewed, unit tests passing, regression tests passing, documentation written, product owner sign-off, and so on. This list of things that the team agrees to always do before declaring a story done becomes the teams “definition of done.”
The Sprint Cycle
The sprint cycle is the foundational rhythm of the scrum process. 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.
The shorter the sprint cycle, the more frequently the team is delivering value to the business.
Sprint Planning Meeting
Part One: “What will we do?”
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. The product owner leads this part of the meeting.
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.
Part 2: “How will we do it?”
In phase two of the sprint planning meeting, the team rolls up its sleeves and begins to decompose the selected stories into tasks. Remember that stories are deliverables: things that stakeholders, users, and customers want. In order to deliver a story, team members will have to complete tasks. Task are things like: get additional input from users; design a new screen; add new columns to the database; do black-box testing of the new feature; write help text; get the menu items translated for our target locales; run the release scripts.
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, sometimes called the stand-up meeting, is:
Daily. Most teams choose to hold this meeting at the start of their work day. You can adapt this to suit your team’s preferences.
Brief. The point of standing up is to discourage the kinds of tangents and discursions that make for meeting hell. The daily scrum should always be held to no more than 15 minutes.
Pointed. Each participant quickly shares:
- Which tasks I’ve completed since the last daily scrum.
- Which tasks I expect to complete by the next daily scrum.
- Any obstacles are slowing me down.
The goal of this meeting is to inspect and adapt the work the team members are doing, in order to successfully complete the stories that the team has committed to deliver.
Note that these are not the stories in the current sprint–those stories are now in the sprint backlog. We recommend one hour per week, every week, regardless of the length of your sprint. In this meeting, the team works with the product owner on:
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.
Inspect & Adapt, Baby
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. What you learn while doing the work in one cycle informs your planning for the next cycle. In scrum, we call this “inspect and adapt”; you might call it “continuous improvement”; either way, it’s a beautiful thing.
All Excerpts From
Sims, Chris & Hillary Louise Johnson. “SCRUM: A Breathtakingly Brief and Agile Introduction.” DYMAXICON.
This material may be protected by copyright.