SCRUM OVERVIEWA Module from the Smidigt! Program

by Ola Berg

Scrum Overview

In 1995 Ken Schwaber and Jeff Sutherland collected a number of

their favorite collaboration techniques in a framework and called

it “Scrum” (a rugby term for when the team huddles at the field

in order to get the ball). The introduction of the term in a

development context and the image of a team that stands close

by each other focused on a common goal, those things came

from a paper from 1986 (“The New Product Development

Game”), and it resonated deeply with the Scrum creators.

Today, Scrum is probably the most known agile collaboration

framework there is. It is so well known that some even believe

that “scrum” and “agile” are synonymous.

Now, there are lots of other agile collaboration techniques you

can use, but Scrum is still often a good starting point as it collects

and presents the most common techniques in a framework that is

easy to grasp (but difficult to master).

In this module you will get a brief overview over Scrum. I will

point out some important details that are often overlooked when

trying to do Scrum, and try to explain some of the dynamics in

the framework.

In this module I will cover the three roles, the five events, and

the three artifacts, but as always: the canonical definition of what

Scrum is and isn't is found in the current edition of The Scrum

Guide, the small pamphlet where Schwaber and Sutherland

defines their framework.

This is an overview of what they have written, together with

some remarks on how to actually make it work.

Ola Berg

Smidigt! © Ola Berg 2016-2017 | @olaberg http://jobbasmidigt.se/ 2017-02-13 All rights reserved. Reproduction without permission is forbidden.

The Sprint

Since there is a continuous generation of insights regarding

users' needs and how to meet them, it is often a bad idea to plan

software development a long time ahead. On the other hand,

since software is complex and often filled with internal

dependencies, it is a good idea to plan how to develop a number

of features together.

Scrum suggest that you divide the time in chunks, at most one

calendar month but often shorter than that: three or two weeks.

This time-unit is called the “Sprint”.

So Sprints are units of time, like days or weeks. Just as

everything that happens during a week happens within a week

since there is no time between weeks, everything happens within

a Sprint.

The next Sprint starts directly after the current Sprint has ended.

The Scrum Team

Scrum is born out of the need for creating, maintaining, and

improving an IT product. A destructive pattern is when all the

product's stakeholders are given access to the developers that do

the actual improvement work. Prioritization won't be clear when

the product lacks a clear leadership.

Scrum mandates that you assign a person, the Product Owner,

who takes responsibility for the product during its whole life-

cycle, by prioritizing everything that should be done with it,

making both technical decisions and business decisions.

With a Product Owner available, the Developers (coders, testers,

requirement analysts, any other needed competence) can do

their work. The Developers are organized in a stable self

organizing team of 3-9 people. They know how to implement

everything that the Product Owner prioritize.

A coaching Scrum Master helps by facilitating this process. The

team of Developers, the Product Owner, and the Scrum Master

make up the Scrum Team.

The Product Backlog and Sprint Planning

At the start of the Sprint, the Developers and the Product Owner

meet in a planning meeting (for a maximum of 8 hours,

facilitated by the Scrum Master) and decide what is going to be

finished during the Sprint. The Product Owner keeps a Product

Backlog, an ordered list of new features for the product with the

most important things at the top.

Many items on the backlog won't be Ready for development

according to the Developers. The items may be too big to fit in a

Sprint or triggers so many unanswered questions that they can't

be completed. If items are important but not Ready, the

Developers offers to refine them during the sprint, if they are

important and Ready, the Developers put them in their Sprint

Plan for implementation.

The Developers know their capacity for the coming Sprint, so the

Developers and the Product Owner can craft a realistic forecast,

even when knowing that unforseeable things will happen.

Review, Demo, and Definition of Done

Normally, the Product Owner can leave the Developers and

return at the end of the Sprint for a Review (maximum 3 hours).

During the Sprint, the Developers have transformed the selected

items from the Product Backlog into an Increment: an

improvement of the product that you actually can release if

needed.

There is an agreement: the Definition of Done, that specifies

what the Increment should have gone through in order to be

releasable: tested, documented, etc. This prevents the quality of

the product to erode.

Sometimes the Increment is valuable to show external people, for

getting valuable feedback and/or inspiring trust between people.

The Product Owner is free to invite others to the Review, or you

can arrange a separate demonstration of the Increment for them.

The information from the Review is used to update the Product

Backlog, plans, forecasts, business cases, et cetera.

Daily Scrum and Abnormal Termination

After Sprint Planning, the Developers and the Product Owners

have agreed upon a sprint goal, and there is a plan for how to

meet the goal given all the other things the Developers may have

to do (like refinement work and other things).

The Developers are self organized, no one knows better how to

implement the Increment than them. In order to self organize,

inspect their progress and adapt the plans, the Developers meet

everyday at the same time and place. They check status from

yesterday, alerts anything that blocks them, and revise their

plans for the day and the rest of the Sprint.

If the sprint goal becomes obsolete, maybe if the Product Owner

sees it that way, the Product Owner may terminate the Sprint.

After termination, the rest of the days are replanned in a new

planning session.

If the Developers see that the sprint goal is threatened, for

instance if there is something that won't be implemented, they

have to alert the Product Owner.

The Retrospective and the Scrum Master

Not only should we inspect the Increment and adapt our plans

for the product. We should also inspect and adapt our very ways

of working, continuously improving them.

The Retrospective (directly after the Review according to the

Scrum Guide) is a meeting for this: deciding what to do

differently during the next Sprint in terms of collaboration,

agreements, and so on. In order to facilitate the process

improvement, and facilitating the process everywhere when

needed, there should be a Scrum Master.

The Scrum Master is in charge of Scrum but has no mandate to

enforce it. Instead the Scrum Master must teach and inspire the

others.

The Scrum Master helps facilitating the planning and the review,

and can be asked to join in and help during the daily Scrum

meeting. It is not uncommon that the Scrum Master is a

developer that assumes extra responsibilities for the people and

the process.

Scrum

Smidigt! © Ola Berg 2016-2017 | @olaberg http://jobbasmidigt.se/ 2017-02-13 You are permitted to copy and distribute this page according to CC-BY-SA 4.0

Scrum Master

Coachning servant leaderResponsible for the process

No mandate, must educate/inspire

Product Owner

Owns the Product BacklogMaximizes productvalue by prioritizing it

Developers

Cross-functional teamDifferent competencesSelf organized, 3-9 ppl.

Retrospective (< 3 hours): The whole Scrum team (Scrum Master, Developers, Product Owner) looks at the Sprint and improves the way they work.

Review (< 4 hours): The whole Scrum team (Scrum Master, Developers, Product Owner) looks at the Increment and updates the Product Backlog.

The Increment is done according to the agreed Definition of Done.

Sprint (< 1 month): A unit of time, often 2, 3, or 4 weeks. EVERYTHING takes place within the sprint. The next Sprint starts directly when the previous Sprint ends.

The Sprint starts with Planning, the Developers meet each day for Scrum, and at the end there is a Review and a Retrospective.

Scrum (< 15 minutes per day): The Developers meet at the same time and place each day to inspect their progress and adapt if needed.

Planning (< 8 hours): The whole Scrum Team plans the next sprint. The Product Owner describes the most important issues to refine and implement, and the Developers forecasts what they can do.

Items that are Ready can be planned for implementation in the Sprint Backlog and items that are not Ready can be planned for Refinement.

Demo: If you have something valuable to show external stakeholders and other interested parties, you can have a demonstration for them of what you have done and getting feedback. Some teams do this as a part of the Review.

Refinement: Making items Ready by retrieving important information from outsiders, thinking about implementation issues, slicing large requests for functionality into smaller pieces etc. Assign a reasonable percentage of team capacity for this and think about it during Planning.

The Developers must notify the Product Owner if the current plan is seriously threatened.

After each Sprint the Developers have created a potentially releasable (tested and documented) Increment of functionality.

The Product Owner can terminate the Sprint andforce a replan if the current plan becomes obsolete, fx. if there is a new important issue.

The Smidigt! Program

The SMIDIGT! program is a series of course modules, group exercises, workshops and tools aimed at helping organizations to achieve a higher degree of agility.

Being agile is about having the ability to investigate customer needs and different ways to meet them, and swiftly change how you work if that is what is needed.

The SMIDIGT! program is created and maintained by Ola Berg, drawing upon his ten years of experience working with agile methods in different organizations.

The Productivity Track is about agile ways of planning and executing different kinds of work: service delivery, product development, administration

The Leadership Track is about fostering self leadership through coaching, delegation, and collaborative decision making.

The Management Track is about organization and agile change management: how to create the preconditions for agility to occur.

Contact: ola.berg@fundament.sehttp://jobbasmidigt.se