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.

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.

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 (eg, “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 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 role in a Nutshell: scrum expert and advisor coach impediment bulldozer facilitator

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.

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

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.

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.

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

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.

A burn chart shows us the relationship between time and scope.

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.

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.

Is the product potentially shippable?

This is a decision for the team.

Does it make business sense to ship what we have at this time?

This is a decision for th...

Additionally, the more frequently the team delivers and demonstrates a potentially shippable product increment, the more frequently the team gets feedback, which...

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.

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.

The output of the sprint planning meeting is the sprint backlog,

The product owner agrees not to ask for additional stories during the sprint, unless the team specifically asks for more.

Each participant quickly shares: What tasks I’ve completed since the last daily scrum. What tasks I expect to complete by the next daily scrum. What obstacles are slowing me down.