The brainchild of a handful of software engineers working together in late 20th Century, scrum has gained the most traction in the technology sector, but is not inherently technical and you can easily adapt the tools and practices described in this book to other industries. You can use scrum to build a better mousetrap, for example, or to run the marketing division of a puppy chow company. You can even use it to collaborate on writing a book -- we did.
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.
This tiny book is a just-the-facts-ma'am introduction to the various moving parts of scrum: the various roles, artifacts and events that occupy the sprint cycle.
A development team represents a significant investment on the part of the business. There are salaries to pay, offices to rent, computers and software to buy and maintain and on and on. 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 itms 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 responsbile 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 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-organization team.
The scrum master is the team's good shepherd, its champion, 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 -- them team's boss. This is a peer position on the team, set apart by knowledge and responsibilites not rank.
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 posess 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 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 product. Generically, they are all referred to as "backlog items." Which backlog itm is technically correct, many scrum teams prefer the term "user story", as it reminds us that we build products to satisfy our users' needs.
This 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:
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. Each time something new is completed the line on the chart moves up. 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. Somethimes the work remaining changes suddenly, when scope is added or removed. 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. Tasks move across the board, providing visibility regarding which tasks are done, which are in progress, and which are yet to be sarted. This visibility helps the team inspect their current situation and adapt as needed. The board also helps stakholders see the progress that the team is making.
Done is a wonderful word; when the team gets a user story done it's time to celebrate! But sometimes there is confusion about exactly what that word "done" means. A programmer might call something done when the code has been written. The tester might think that done means that all of the tests have passed. The operations person might think that done means it's been loaded onto the production servers. A business person may think that done means we can now sell it to customers, and it's ready for them to use. This confusion about what "done" means can cause plenty of confusion and trouble, when the salesperson asks why the team is still working on the same story that the programmer said was done two weeks ago!
In order to avoid confusion, good scrum teams create their own definition of the word "done" when it is applied to a user story. They decide together what things will be complete before the team declares a story to be done. The team's definiton 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 team will likely print out their definition of done as a checklist, and post it next to their task board. When the team thinks a story is done, they all gather around and review each item, to confirm that it has been completed. Only then will the team declare the story as done.
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. At the end of your sprint, you will be demonstrating working software.
The more frequently the team delivers a potentially shippable product increment, the greater freedom the business has in deciding when and what to ship. Notice that there are 2 separate decisions here:
Additionally, the more frequently the team delivers and demonstrates a potentially shippable product increment, the more frequently the team gets feedback, which fuels the important inspect-and-adapt cycle. The shorter the sprint cycle, the more frequently the team is delivering value to the business.
As of this writing, it is commmon for scrum teams to work in sprints that last two weeks, and many teams are starting to work in one-week sprints. Much of the original writing about scrum assumed a month-long sprint, and at the time that seemed very short indeed!
The table that follows maps out the various meetings you would schedule during a one-week sprint. You don't have to call them meetings if you're allergic to the term or consider meetings to be a form of repetitive stress injury; you can call them ceremonies, as many scrum adherents do. The meeting lengths shown are an appropriate starting point for a team doing one-week sprints.
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 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 merge 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.
One by one, in priority order, the product owner presents the stories he whould like the team to complete during this sprint. As each story is presented, the team members discuss it with the product owner and review acceptance criteria to make sure they have a common understanding of what is expected. Then the team members decide if they can commit to delivering that story by the end of the sprint. This process repeats for each story, unntil the team feels that they cann't commit to any more work. 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. Remember that stories are deliverables: things that stakeholds, 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 product owner should be available during this half of the meeting to answer questions. The team may also need to adjust the list of stories it is committing to, as during the process of identifying tasks the team members may realize that they have signed up for too many or too few stories.
The output of sprint planning meeting is the sprint backlog, with their associated tasks. The product owner agrees not to ask for additional stories during the sprint, unless the team specifically asks for more. The product owner also commits to being available to answer questions abou the stories, negotiate their scope, and provide product guidance until the stories are acceptable and can be considered done.
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:
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. The inspection happens in the meeting; the adaptation may happen after the meeting. This means that the team needn't solve problems in the meeting: simply surfacing the issues and deciding which team members will address them is usually sufficient. Remember, this meeting is brief!
In this meeting you will be discussing and improving the stories in your product backlog, which contains all the stories for future sprints. 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 to:
Define and Refine Acceptance Criteria
Each user story in the product backlog should include a list of acceptance criteria. These are pass/fail testable conditions that help us know ehn then the story is implemented as intended. Some people like to think of them as acceptance examples: the examples that the team will demonstrate to show that the story is done.
Story Sizing (Estimation)
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. While the product owner may do much of this work on their own, story time is their chance to get help from the whole team.
As of this writing, the story time meeting isn't an "official" scrum meeting. We suspect it will be in the future, as all of the high performing scrum teams we know use the story time meeting to help keep their product backlog groomed.
This is the public end of the sprint; invite any and all stakeholders to this meeting. It's the team's chance to show off its accomplishments, the stories that have met the team's definition of done. This is also the stakeholders' opportunity to see how the product has been incrementally improved over the course of the sprint.
If there are stories that the team committed to but did not complete, this the time to share that information with the stakeholders. Then comes the main event of this meeting: demonstrating the stories that did get done. Undoubtedly the stakeholders will have feedback and ideas, and the product owner and the team members will gather this feedback, which will help the team to inspect-and-adapt the product.
This meeting is not a decision-making meeting. It's not when we decide if the stories are done; that must happen before this meeting. It's not when we make decisions or commitments about what the team will do during the next sprint; that happens in sprint planning.
How long should be sprint review be? We recommend scheduling one-half to one hour for every week of development. That is, if you have a one-week sprint, then this meeting might be 30 to 60 minutes. If you have a two-week sprint, then this meeting might need one to two hours. After you have done it a few times, you will know how long your team needs--inspect and adapt!
While the sprint review is the public end of the sprint, the team has one more meeting: retrospective. Scrum is designed to help teams continuously inspect and adapt, resulting in ever-improving performance and happiness. 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. We recommend 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. It's about process improvement.