Scrum: a Breathtakingly Brief and Agile Introduction

by Chris Sims

Scrum recognizes only three distinct roles: product owner, scrum master, and team member

Is this a mandate by SCRUM manifest? Or there can be more roles?

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.

the product owner maximizes the value realized from the team’s efforts is to 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

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, 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 ke...

The scrum master is not—we repeat, not—th...

This is a peer position on the team, set apart by knowledge and respo...

Must the SCRUM master be peer to the team? Should scrum master be someone superior in ranking than the team members? Can the scrum master be someone from outside the team? Or must be from within the team? Must the scrum master have same level of expertise (technical or other) as the team members?

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

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

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.

What is rational behind this number? What research has been done on the implication of having a scrum team of 10 or 15 or 20???

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.

If the product owner is setting the priorities of the stories, then should there be a single product owner for all products or one product owner for each product or one product owner for multiple similar products? Who decides which product is TOP priority among all the products?

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

A story is something a team delivers; a task is a bit of work that a person does.

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 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 is a decision for the team.

This is a decision for the business.

The product owner leads this part of the meeting.

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.

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 product owner should be available during this half of the meeting to answer questions.

the list of all the committed stories, with their associated tasks.

The daily scrum should always be held to no more than 15 minutes.

Working software is the primary measure of progress.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.