Scrum: A Breathtakingly Brief and Agile Introduction

by Chris Sims

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. 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).

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.

make sure the team fully understands the requirements.

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.

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.

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 coach impediment bulldozer facilitator

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.

The role of each and every team member is to help the team deliver potentially shippable product in each sprint.

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

how many team members should a scrum team have? The common rule of thumb is seven, plus or minus two.

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.

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 impl...

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. 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. Sometimes 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.