Certied ScrumMaster

Certied ScrumMaster

Contents
Section Agile Foundations Scrum Flow Scrum Team Development Team Product Owner ScrumMaster Project Management Roles Team Chartering Product Backlog Agile Estimating User Stories Release Planning Sprints Sprint Backlog Sprint Planning Daily Scrum Page Section 3 Controlling and Reporting 13 Sprint Review 21 Scaling and Distributing Scrum 25 Agile Retrospectives 33 38 43 45 57 66 81 102 108 116 124 135 Contact, Copyright & Attribution Page 143 154 161 177 189

Agile Foundations

Different Process Types

Defined Process: may be complicated Follow rules, avoid deviations

Empirical Process: complex inspect and adapt constantly

(source: http://www.flickr.com/photos/mikett/780458761/

Software Development
Software development is (most of the time) an empirical process: The environment and prerequisites are incompletely dened Requirements change over time The knowledge about the best approach is incomplete The system is complex As a result, success depends on: Getting early and frequent feedback for the system under development, in terms of requirements and approach - e.g. by demonstrating and evaluating running increments early and often. Making it easy for the participants to react to this feedback and adapt the requirements and approach - e.g. by making it easier for the participants to steer development. Effective communication between all of those involved in developing the system so that the business and technical knowledge is available to those who need it. The most effective means of communication is often the spoken word. The agile principles are rooted in these insights.

The PDCA Cycle

Environment for Empirical Process Control

Solving complex problems needs constant adaption and requires:
Creativity Initiative Individuals and teams that learn

So that this can ourish, a culture is needed which values:

Trust: not trying to place blame when errors occur and appreciating the learning opportunities Respect: people are not resources

These are codied in the Agile Manifesto and the accompanying principles:
Written in 2001 by 17 prominent gures in the eld of software development

The Agile Manifesto

Individuals and interactions
over

Processes and tools Comprehensive documentation Contract negotiation Following a plan

Running software

over

Customer collaboration Responding to change

over

over

That is, while there is value in the items on the right, we value the items on the left more

The Agile Manifesto: Agile Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efcient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indenitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reects on how to become more effective, then tunes and adjusts its behavior accordingly.

Far from Agreement Anarchy

Requirements

Complex

Complicated

Close to Certainty

Close to Agreement

Simple
Far from Certainty

Technology

Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

Agile Development is for Complex Problems

10

The Cynefin Framework

Probe Sense Respond

Sense Act Respond

Act Sense Respond

Sense Categorise Respond

Source: Wikipedia

11

Complexity and Leadship Style

(Snowden & Boone, Harvard Business Review, November 2007)
Type Chaotic Characteristics High Turbulence No clear cause-and-effect Unknowables Many decisions and no time Flux and unpredictability No right answers, emergent solutions Many competing ideas Need for creative, innovative approaches Leaders Job Immediate action to re-establish order Prioritize and select actionable work Look for what works rather than perfection Act, sense, respond Create controlled environments for experiments Increase levels of interaction and communication Help generate ideas, Monitor for emergence Probe, sense, respond Servant leadership Utilize experts to gain insights Use metrics to gain control Sense, analyze, respond Command and control Use best practices Extensive communication not necessary Establish patterns and optimize to them Command and control

Complex

Complicated

More predictability than unpredictability Fact-based management Experts work out wrinkles

Simple

Repeating patterns and consistent events Clear cause-and-effect Well established knowns Fact based management

12

Scrum Flow
The Essentials of Scrum

13

Scrum in 5 Minutes
The product owner is responsible for creating and prioritising the product backlog, a dynamic list of features for the product. Anyone can contribute to the product backlog but the product owner has the nal say on prioritisation. Before each sprint, the team decides in a sprint planning meeting, how many of the highest prioritised features they can deliver during the sprint. They decide what tasks are necessary to realise these features and enter them into the sprint backlog. During the sprint, the team synchronises in a daily scrum meeting and follows progress in the burn down chart. The ScrumMaster coaches the team, removes impediments and ensures that the team is able to work effectively. During the sprint, valuable functionality is developed and a potentially shippable product increment created, which is demonstrated by the team during a sprint review meeting. The scrum team then holds a retrospective and identies how they can work together more effectively during the next sprint.

14

The Essentials
Sprint
An iteration with a xed duration

3 Documents
Product Backlog Sprint Backlog Sprint Burn Down Chart

4 Meetings
Sprint Planning Daily Scrum Sprint Review Retrospective

3 Roles
Product Owner ScrumMaster Development Team

15

Scrum Flow
24 Hours

Sprint Goal
Return

Sprint 2-4 Weeks

Sprint Backlog
Return Cancel Voucher Gift-wrap Cancel Gift-wrap Voucher

Potentially shippable product increment

Product Backlog

source: Mountain Goat Software, LLC

16

No Changes during a Sprint

New Requirements

17

Quelle: David Harvey

18

Scrum Roles
Team
Self-organising responsible for realising the product increment

Other stakeholders
coordinated by the Product Owner

ScrumMaster
removes impediments responsible for process

Product Owner
denes the product responsible for the results

19

Scrum Values
Commitment Focus Openness Respect Courage

20

The Scrum Team

21

Scrum Roles
There are three roles in Scrum:
The Product Owner The Development Team The ScrumMaster

The people who fulll these roles are called collectively the Scrum team. All others are outside of the Scrum team.

22

The Scrum Team

Scrum Team

Others

Product Owner

Development Team

Scrum Master

23

Exercise: Scrum Roles

In table groups, discuss the following questions for 5 minutes and then report back:
Why are there just three recognized roles in Scrum? Are the others also important for the success of projects? If so, how can we effectively and efciently communicate with the others?

24

The Development Team

25

The Development Team

Empowered and autonomous Organizes itself and its work Size: 7 2 Cross functional - all necessary skills to deliver a product increment should be present Ideally full-time and collocated Selects the requirements to be realized in a Sprint and commits to the Sprint goal Collectively responsible for meeting this commitment and demonstrating the new product increment at the end of the Sprint
26

Team Phases
Norming Storming

Performing

Forming

(Tuckman 1965)
27

Team Phases
Performing

Forming

Storming

Norming

Adjourning

(Tuckman 1965, 1970, Bates, 1965)

28

Team Phases
Forming
Individual roles and responsibilities are not clear Team requires clear aims and objectives from a leader

Storming
Team members vie for position as they attempt to dene their own position Conict is normal and not necessarily negative A coaching leadership style can help the team to remain focussed Sometimes a team remains locked in this phase

29

Team Phases
Norming
Team establishes its own way of working Important decisions are made by the team A facilitation and enabling leadership style supports the team

Performing
The team has a deeper understanding of what it is doing and why it is doing it (strategic awareness) Disagreements are resolved constructively Real feeling of collective responsibility and belonging Under stress, a team may fall back into the storming phase

30

Exercise: Team Forming

In table groups, discuss the following questions for 5 minutes and then report back:
How long does it take to get to performing for a new team? How long should a Scrum team stay together? What can be done to help the team to get to performing more quickly and who is responsible for this?

31

Team Forming: Our View

It can take a new team 3-6 months to get to performing. Some teams never make it. Therefore Scrum teams should stay together beyond the timeframe of many projects. Team members come and go but a core can remain. Projects are important as a source of nance but it is often useful to take a product view - the ongoing development of an IT system should be carried out by the same team. Both the Product Owner (in terms of setting clear objectives and helping the team to focus) and the ScrumMaster (in terms of coaching and facilitation) can help the team through forming, storming and norming to performing.

32

The Product Owner

33

Role of the Product Owner

Denes product features, resolves open requirements and business issues Prioritizes features depending of their value and the associated risk, consolidates wishes of different stakeholders Determines delivery date and scope of the product Adapts feature list and priorities before each sprint Accepts or rejects results Is responsible for the ROI of the project

34

Starting a Project
Product owner

Product Backlog Idea User User Epic Story Story Vision User User User Story Story Story
Team

Prioritize

Estimate

Release Plan
Other sources Creativity User centered Design

Sprint Planning

35

Requirements Engineer vs. Scrum Product Owner

In Scrum, we embrace change, i.e.
We do not expect that requirements are immutable or completely dened at project start We rely more on face-to-face communication instead of written documentation Requirements are more the result of negotiations than contracts

The product owner constantly supports the team with information and feed-back The product owner typically needs 50 to 100% of his/her time for playing the role properly
36

Who Should be a Product Owner

Should be in power to decide Should know the application area Should understand the consequences of business and technical decisions Can be a line manager
When he respects the self-management of the team When he does not has objectives conicting with the project goal

37

The ScrumMaster

38

No Power Left Over for the ScrumMaster

The ScrumMaster is a servant leader His strength is the lack of power Especially for new teams, being a ScrumMaster is a full-time job

39

Role of the ScrumMaster

Ensures compliance with Scrum values and principles Removes impediments Ensures the Scrum team is completely functional and productive, helps the team to organize its work Coaches team and product owner Supports the close cooperation between all project participants Protects the team from external disturbances

40

Qualications of the ideal ScrumMaster

Moderation
Organize effective meetings Find techniques to develop the teams creativity

Coaching, facilitation
Help the team develop Support individual team members to exploit their potential

Experience in software development

Helping the team to continuously improve its work

Make sure the team members have fun during work

41

What a ScrumMaster is Not

A project manager A line manager Also functioning as a product owner A proxy for the absent product owner All these smells are impediments and will certainly lead to less focus and productivity

42

Exercise: Project Management Responsibilities?

What happens to the project management responsibilities in Scrum?
Scope Time Cost Communication Risk Quality

Do we need a project manager as well as the three Scrum roles? Discuss in your table groups for 5 minutes and then report back
43

Project Management Responsibilities: Our View

Responsibility Scope Time Cost Communication Risk Quality Product Owner (release) (release) (scope) Team (sprint) (sprint) (sprint report) (testing) ScrumMaster (process)

44

Team Chartering
Creating powerful working agreements, a denition of ready and a denition of done

45

Team Charter
A team charter is the working agreement of a team
The team puts into writing the work practices it agrees should be adhered to It contains basic agreements, engineering rules, communication rules and commitments The denitions of ready and done are core parts of the team charter

Can be part of a larger project denition or a separate document

46

Who owns the Team Charter?

The team writes, takes responsibility for and owns their charter With input from the ScrumMaster and the Product Owner For a particular organization, there might be mandatory entries such as
the technology to be used additions to the denition of done, e.g. based on the companys CMMI implementation or other governance compliance requirements

47

Content of a Team Charter

Basic agreements Technology Team communication rules Denition of Ready Denition of Done

48

Meetings
Daily Scrum: time, location, follow-up discussions, late-penalties, participation of chickens Sprint planning meeting: time, structure, attendance Sprint review: structure, attendance, preparation, rules for demos Retrospectives: structure, attendance, techniques Issue resolution: impediment resolution, requirement ambiguity resolution Tracking: burn down chart on task board or electronically, update before every daily scrum

49

Planning and Estimation

Units for estimating product backlog items - e.g. Story Points Recommended maximum size of task and product backlog items Rules for when estimation should take place - e.g. that all product backlog items should be estimated before sprint planning

50

Engineering Rules
Continuous integration and deployment: which tools, how team members are notied if there is a problem Testing: which tools, coverage of automated unit tests and automated acceptance tests Test driven development Pair programming, audit and review rules, common code ownership Coding standards Documentation standards
51

Communication Rules
Respectful conversation Active listening How to deal with stakeholders What the team expects from the product owner. For example:
timely feedback prioritized product backlog at sprint planning the team could encourage the product owner to write a separate charter with his/her commitments

52

Denition of Ready
Denes how product backlog items (e.g. stories) will be continuously rened and prepared for future sprints (product backlog grooming) Typically includes:
Requirements workshops Estimating workshops Time for research

Product owners can expect teams to spend up to 10% of their capacity on helping to groom the product backlog.

53

Denition of Done
Denes when:
Tasks Product backlog items (e.g. stories) The product increment

are considered done. Can be implemented as checklists for these three levels which are displayed prominently in the team room.

54

Benets and Pitfalls of a Team Charter

It helps to uncover unclear expectations and ambiguous project goals It helps the team to develop a common understanding of their work and to develop good working relations inside and outside of team For new teams, this is likely one of the rst common activities and can help team formation. Give the team some room to breathe Keep it short: restrict the charter to the appropriate items. Items can always be added as a result of retrospectives

55

Project Charter in Traditional Project Management

In traditional project management, a project charter has a somewhat different meaning:
Typically, a senior manager writes it It denes the project purpose, scope and denition of success The closest equivalent in Scrum is the product vision.

When an organization is new to Scrum: be careful to communicate the specic purpose and structure of the team charter so that there are no misunderstandings

56

The Product Backlog

57

Requirements in Scrum
In Scrum collecting requirements and realization of the requirements overlaps, we dont separate requirements and realization phases Requirements in Scrum are emergent
We will discover more about how to meet the customers needs as the project progresses Existing requirements change New requirements are discovered

58

The Product Backlog

Prioritised list of requirements
Managed by the product owner but anyone can contribute ideas

Characteristics
Emergent Prioritized
By the product owner

Estimated
By the development team
59

The Product Backlog is Not ...

A complete list of everything that might be required A denition of solutions instead of requirements A contract between the customer or product owner and team A list of activities required to realise the requirements

60

Levels of Granularity
The product backlog will contain items with typically three levels of granularity:
Fine grained, high priority items. Requirements small enough and detailed enough so that they are ready for the next sprint. These are typically represented as normal user stories. Medium grained, medium priority items. Requirements that can be roughly estimated but that need breaking down before realisation. Typically represented as larger user stories. Coarse grained, low priority items. High level requirements that are often represented as as epic stories.

61

Levels of Granularity
Fine-grained. Ready for next sprint. User stories.

Priority

Medium-grained. Larger user stories.

Coarse-grained. Epic stories.

62

Storing the Product Backlog

There are many ways to store the product backlog:
As a collection of index cards or post-its on the wall On a ip-chart In a requirements management tool In Excel

63

Storing the Product Backlog - Example

Ref. no. Title User Story Acceptance Criteria Estimate (Story Points)

Auto Insurance Discount

As an insurance agent I want to offer a potential customer a discount so that I can win her business

Fixed list of discounts selectable (5, 10, 15%)? Displayed in policy summary? Transmitted to mainframe correctly?

List of Discounts Awaiting Approval

As a discount approver I want to see a list of discounts waiting for approval so that I can control my budget

Monetary impact of discount visible? List of open discount cases visible?

Accept, Reject or Change Discount

As a discount approver I want to be able to accept, reject or change a discount so that I can control my budget

Accept a discount, check DB updated Reject a discount, check DB updated Change a discount, check DB updated

64

Using Index Cards on a Wall to Represent the Product Backlog

13

65

Agile Estimating

66

Levels of Planning
Agile projects contain typically: Release Planning Goal: to predict the number of sprints and teams High-level estimation of product backlog items Covers a period of of 3 to 6 months (dependent on project or product) Initial release planning at start of project (or application for funding) Updated after each sprint Sprint Planning Goal: to achieve a commitment from the team for the sprint goal Detailed estimation of the necessary tasks to implement the selected product backlog items Occurs at sprint start Upated every day based on the remaining effort The same basic planning method is used independent of level

67

Release Planning
We estimate features in Story Points Story Points: Unit-less Relative in comparison to other estimations Express the size (relative effort) of a feature Velocity: How many story points did the team implement in a sprint Advantages: Story Point do not become obsolete Story Points are only an estimate of size Relative estimates are simpler and less fraught with connotations In story points we estimate faster

size 300 Points

est. velocity V = 20

duration 15 Sprints

68

Estimating at Sprint Planning

We estimate tasks in work units (e.g. in days) Approach:
product owner presents a feature team claries (with further inquiries) details team breaks requirements down into tasks team estimates the time necessary to implement the task in work units We repeat this with the next highest prioritized feature, until the sprint capacity is exhausted

69

Estimation
How large is a backlog item in comparison to others? Triangulation (compare with two other items or tasks) Use the teams experience Use expert knowledge from outside the team if necessary Dont lose the focus being overly precise Its just an estimate!

70

Noahs Ark: most seats are taken ...

71

Animal Points
Assign animal points (range 1 - 40):

chicken horse

2 13
lion

lamb Echidna

8
giraffe

cat

40
72

Echidna?
73

74

The Art of Scaling

Can I tell a 1-point story form a 2-point story ? Can I tell also a 17-point story from a 18-point story ? Use reasonable steps of size, e.g.: T-Shirt size XS, S, M, L, XL, XXL 1, 2, 4, 8, 16 1, 2, 3, 5, 8, 13 Use 0 oder if necessary Keep the scale !

75

Planning Poker
An estimation method based on Wideband Delphi Estimation in story points (size-/complexity points) or units of time (e.g. hours) scale: 0 - - 1 - 2 - 3 - 5 - 8 - 13 - 20 - 40 100 (inspired by the Fibonacci sequence) Approach: The item to be estimated is discussed and a common understanding developed (for product backlog items, the Product Owner describes the requirement and the team asks questions) Each team member makes up his/her mind and makes a (concealed) estimate The estimates are revealed simultaneously The results, especially the outliers, are discussed Estimation continues until until agreement is reached

76

Example: Planning an Open Space Conference

Product backlog
Find and reserve a conference hotel Invite participants Prepare soft drinks and coffee Reserve tables for lunch Compile costs Prepare moderation material

77

Prepare Moderation Material

Johann

Kurt

Richard

5 3

Amy

Karlheinz

5 13

5
78

Advantages of Planning Poker

Historical experience can be used Expert knowledge of the whole team with different points of view is leveraged Avoids manipulation by dominant team members Facilitates communication especially with the product owner Eliminates differing senses of time Team achieves agreement on the results Very efcient approach with excellent results

79

More Information
Mike Cohn: Agile Estimating and Planning Prentice Hall 2005

80

User Stories
A promise for a conversation

81

What is a User Story?

A user story describes in natural language a business scenario in terms of who, what and why It is intentionally short - traditionally on a index card - and consists typically of no more than two sentences. It does not try to cover all details - it is the starting point of a conversation between business and development A user story represents a feature to implement. In fact, we recommend to build your product backlog from user stories
82

Scope of a User Story

User stories can be very general (we call these epics) or very specic Typically a product vision consists of a few epics.
The product owner decomposes the most valuable epics into smaller stories and prioritizes those with the highest business value or highest risk The team estimates them and decomposes then into tasks for the rst sprint

In parallel to the team working on the sprint, the product owner will look ahead and decompose more epics

83

Structure of a User Story

It describes a scenario in terms of who, what and why
As a (role: who wants something) I want (what: business requirement) because (why: benet, business value).

Describes rst acceptance criteria to describe the scope.

Can be the starting point for writing acceptance tests

84

User Story: proposed format

Story Content Size Role

Business Objective

85

User Story Format Proposal II

More details, tests ...

86

Who
Should be an end-user role Should describe the role with as much precision as possible
Bad: As a user Good: As a secretary of a frequent yer

Helps to understand the aim of the story

87

What
Should describe a clear scenario Should contain the business scenario, not the technical solution

88

Why
Represents the business value, when the problem is solved Is indispensable to keep all participants focused on the business value

89

Acceptance Criteria and Tests

Acceptance criteria guide the writing of acceptance tests They show that a story is implemented as expected Hint: write the critical tests on the back of the index card

90

What is a good User Story?

If in doubt INVEST! Independent - avoid problems in prioritizing stories Negotiable - a story is not a contract Valuable - for the business Estimable - the stories build the basis of our project plan through the product backlog Small - large stories should be decomposed Testable - if a story is not testable maybe it doesnt have any real value?

91

User Stories are Vertical

Client Web-Server App-Server DB-Server
Technical architecture view: e.g. Client/Server architecture

Presentation Control Application Data management Data storage

Business architecture view: layer model

C/S architecture or business layers: User Stories should cover all layers
92

Bad Story

Independent Negotiable Vertical Estimable Small Testable

93

Good Story

Independent Negotiable Vertical Estimable Small Testable

94

Good Story Acceptance Criteria

95

Lets Write a User Story

Exercise Write a user story I want a cup of tea (or coffee) Time box: 5 minutes Structure: As a I want because At least 3 acceptance criteria Use the provided index cards Write acceptance criteria on the back of the cards

96

Splitting User Stories Example 1 - Search

Example: search functionality in an application Problem: a large form with 20 input elds for search criteria Approach: partitioning of the story into functional groups
Search for locked users with basic criteria Search for locked users with additional criteria Search for business prospects Search for guest users last night

97

Splitting User Stories Example 2 - Record Access

Example: a story is too large to complete in one sprint Approach: partition by functionality CRUD operations
Create Read Update Delete

98

Splitting User Stories

Performance test as a separate story Sometimes we can grant an exception
When an analysis is expensive: could be a separate story (or task) Very small stories can sometimes be combined

99

What a User Story is Not

A use case
Use cases are normally more detailed and may form a detailed specication. A user story is a reminder to have a conversation User stories are much easier to scale/decompose from initial large stories (epics) to smaller stories

A complete specication
We may need additional documentation for traceability, compliance or other reasons

100

More on User Stories

Sources
Mike Cohn: User Stories Applied Addison Wesley Mike Cohn on YouTube, Bay XP Meeting 2007 http://www.youtube.com/watch?v=fb9Rzyi8b90

101

Release Planning

102

The Release Planning Process

Stock the Product Backlog

Estimate Backlog Items

Determine Velocity

Generate Release Plan

103

Determining the Initial Velocity

Three approaches (in order of preference)
Execute 2-3 sprints and measure the velocity (average) Use historical data to make an estimate of the velocity Perform a simulated sprint planning and estimate how much can be delivered in a sprint

104

Updating the Release Plan

Do Sprint
actual velocity

Update Release Plan

105

Initial release plan with assumed velocity = 10

Sprint 1

Story A 3 Story B 5 Story C 2

Sprint 2

Story D 5 Story E 5 Story F 1

Sprint 3

Story G 3 Story H 3 Story I 3

106

Updated release plan after sprint 1 with actual velocity = 8

Sprint 1

Story A 3 Story B 5 Story C 2 Story D 5 Story E 5 Story F 1

Sprint 2

Sprint 3

Story G 3 Story H 3 Story I 3

107

Sprints

108

Product Increment
The sprint goal always represents a potentially shippable product increment containing new valuable business functionality This keeps the teams focus on value creation and helps to keep the stakeholders supportive of the project

109

Uninterrupted Work
The team should not be exposed to changed requirements during a sprint: this is a serious impediment and can be disastrous to the teams morale and velocity Exception: High-priority support. It is often helpful to reserve some capacity for support (e.g. 20% dependent on context). In addition, the team may use up to 10% of its gross capacity for lookahead and preparation for future sprints

110

Keeping Track
The team keeps track on the progress by updating the sprint backlog at least daily. They do this by:
Estimating the work remaining for the tasks that they currently have in progress Making sure that newly discovered tasks are captured, entered into the sprint backlog and estimated

The burn down chart visualizes the status and provides the information for adaption
by removing backlog items if progress is slower than expected by adding backlog items and re-planning All changes at the product backlog item level must be authorized by the product owner

111

Sprint Burn Down

112

Overhead
The overhead for planning, review and retrospective should be kept to the necessary minimum
Some authors require not more than 10% of the time

The team members are expected to contribute about 10% of their time in additional planning, research and look-ahead for future sprints
The number depends on the project phase, the complexity of the area and technology and the experience of the team members

113

Impediments and the ScrumMaster

The ScrumMaster logs impediments during a sprint. This can be
An impediment log An impediment burn down

The ScrumMaster works constantly to remove impediments so that work can continue without interruption

114

Abnormal Termination
When
the sprint goal becomes obsolete (e.g. due to changed market conditions) External disturbances become so dominant that the sprint goal cannot be reached (e.g. if despite the ScrumMasters best endeavours several members have been removed from the team)

The product owner and ScrumMaster may decide to cancel the sprint and re-plan a new sprint
This should remain an extreme measure when all other efforts to remove impediments have failed

115

The Sprint Backlog

116

The Purpose of the Sprint Backlog

The sprint backlog helps the team to reach the sprint goal
It contains the common time management It helps to keep the team focused

Living artifact

117

What Does a Sprint Backlog Contain?

After sprint planning, we will have broken down product backlog items into tasks
The sprint backlog contains a list of these tasks The tasks may be grouped by product backlog item. Only nished backlog items represent created value

Estimated remaining effort for each task

The team tracks the remaining effort. When a task is nished, the remaining effort is 0. Newly discovered difculties can increase the estimated remaining effort

The team updates the sprint backlog continuously

118

Sprint Backlog and Daily Scrum

It is useful to have the sprint backlog available and visible during the Daily Scrum, where the team members coordinate their work For optimum coordination, the team members should be able to report mainly about nished work It is therefore best to keep the tasks small (ideally less than one working day)

119

Task Board and/or Electronically

If possible, use a task board in the team room
It is visible It is a focus for discussions after the Daily Scrum

For distributed teams, you probably need to maintain it electronically (e.g. with Excel)

120

Task Board

121

Sprint Backlog on Excel

122

What the Sprint Backlog is Not

Performance tracking and -management
The team is responsible for reaching the sprint goal, not individual members

123

Sprint Planning

124

Goal of the meeting

At the end of the planning meeting
The product owner and the team have agreed on a sprint goal The team has committed to implement a number of product backlog items based on its expectations what can be done: commitment based planning The product owner knows what to expect as new functionality The team knows what to do next

125

Before Sprint Planning

The product owner makes sure that product backlog is up-to-date and that backlog items are prioritized and estimated The team helps the product owner in estimating and if necessary, decomposing user stories
Sometimes, this is done in a meeting called sprint planning 1 In some projects, this can be complicated: team members have 5-10% of their gross capacity available to help the product owner prepare for future sprints

Organize the meeting: venue, invitations, working material

126

Agree on a Sprint Goal

The product owner presents the sprint goal The team and the product owner discuss it
Do team members have a common understanding? Is it realistic?

Make it visible
e.g. on a prominent location of the task board

Do not skip this step, it is important for focused work during the sprint

127

Team Capacity
Example capacity breakdown:
Gross capacity: 100% Scrum process overhead (meetings): 10% Lookahead/preparation for future sprints: 10% High-priority support: 25% Available for achieving sprint goal: 55%

Recommendation:
Before sprint planning, ask each team member to state how many days they will be available during the next sprint

128

Sprint Planning
The team takes the highest prioritized backlog item
discusses it with the product owner decomposes it into the necessary tasks estimates the tasks

Repeat this until the teams capacity is used up Advantages

Only backlog items that the team commits to are estimated Better smoothing of team workload

129

Sprint Planning - Alternative

Some teams use velocity as the basis for deciding how much to include in the sprint backlog. This approach is derived from the Extreme Programming Planning Game The product owner and the team agree on a realistic set of product backlog items
Based on the previous velocity of the team and the estimated complexity of the user stories In this phase, the product owner answers questions clarifying functionality and scope of the stories

Advantages
It is easier to ensure the conceptual integrity of the product increment

130

Sprint Planning: Just-intime Analysis and Design

While decomposing user stories, the team gains a technical understanding of what must be done
The team analyzes the problem from a technical perspective The team designs a solution and agrees to it

Sprint planning is as much about outline design as it is about planning This is a cornerstone of a teams common understanding and team forming. Do not try to skip this. It is worth every minute.

131

If the Planning is too complex

The duration of a sprint planning should be limited, e.g. 2 hours for a 2 week sprint, or 4 hours for a 4 week sprint If the time box is exhausted
Schedule another meeting Next time, help the team to prepare for the next sprint planning meeting during the sprint

Do not make compromises on planning quality

132

Spreading the Work

When you have specialists in your team
Make sure the sprint planning distributes the load equally Discuss how work can be distributed among team members. Note that some members might need help or education to be able to take on other tasks. Skill monopolies are a potential impediment and a project risk We suggest that the team uses pair programming to reduce skill monopolies where appropriate Check what other stories you can add to the sprint based on the required skill prole

133

Special Tasks
Identify necessary technical tasks
Sometimes you need technical user stories Technical tasks can be part of such a story or be standalone

Educational tasks
May be useful to tackle future requirements May be useful to break skill monopolies

Explain to the product owner why such tasks or stories are necessary and can increase the ability to deliver future sprints. However, the product owner should decide

134

The Daily Scrum

135

Goal of the Daily Scrum

Each team member should know what the other team members are doing and what they have achieved To achieve this, each team member must report about his/her work in enough detail to make it transparent to the others The Daily Scrum is a key part of inspect and adapt. It allows the team to reect on what has been achieved during the sprint and to adapt their behavior to maximize the likelihood of achieving the sprint goal.

136

Conducting a Daily Scrum

Every day at the same place and at the same time
Do not allow the daily Scrum to become a source of discussion, distraction or other complexities

Insist that the Daily Scrum begins on time

It can be sign of lack of respect to make other wait for you

Keep to the time-box of 15 minutes

If additional discussion is need, schedule a separate meeting or meet ad-hoc directly after the Daily Scrum

Only Scrum team members speak - others are welcome but should listen only
If other stakeholders or managers want to comment during the meeting, ask them kindly to defer their comments until after the Daily Scrum

Tip: repeat the daily Scrum rules at the beginning of the meeting every few days or if there have been rule violations recently

137

How is this Achieved?

Each team member answers exactly three questions
What have I done since the last meeting? What will I do until the next meeting? What impediments/problems do I have?

All team members should participate daily

If necessary, get team members on the phone If a team member is in not available for some reason, someone should report for him/her

138

After the Daily Scrum

The ScrumMaster works on removing the impediments When additional questions came up, e.g. technical problems or detailed coordination of tasks, the concerned team members discuss them or schedule additional meetings. Other team members need not take part.

139

Tracking Progress
At the end of the Daily Scrum, the sprint backlog and the burn down chart should be updated
If the team has a task board, the team updates it. In some teams, the index cards are only moved during/after the Daily Scrum, in others the task board is updated as soon as a task is nished or added Update the sprint backlog. In some teams individual team members are responsible, in others teams the ScrumMaster agrees to do this on the teams behalf Update the burn down chart

After the meeting

Discuss necessary adaptions with the product owner, e.g. removing backlog items from the sprint Start working on the removal of the impediments

140

What Can Go Wrong: Smells

As a ScrumMaster, do not control the meeting. Make sure the team is in charge. Observe the team for dysfunctional contributions, e.g.:
Team member reports the same task every day Team member is not clear about his/her achievement

141

What the Daily Scrum is Not

A reporting meeting for anyone other than the team members themselves A meeting to receive new instructions from the product owner

142

Controlling and Reporting

143

Empirical Process Control

Inspect and adapt is a fundamental part of agile development and Scrum But: what is the goal of adaption?
Finding the best way to create value Making the project the best learning experience for the team

144

Effects of Measuring
Individual performance Lines of code Competing Individuals Un-refactored code

On-time delivery

Sloppy code

People will change their behavior depending on how you evaluate them
145

Feed-Back Loops in Scrum

Daily
Evaluating the remaining work, updating the sprint burn down chart

Sprint
The teams velocity during the sprint, updating the release burn down chart and the release plan

Release
Deploying value to the customer

146

Reports
Sprint burn down chart Shows the total remaining effort for the team Additional variants: counting open tasks, counting open stories Sprint end report Optional but can form a useful of the sprint Compiled by ScrumMaster or team Task board Release burn down chart Shows remaining functionality by sprint Additional variant: parking lot chart shows functionality by category Velocity diagram Shows velocity by sprint

147

Sprint End Report

Suggested contents
Sprint start date and end date Team members, days planned and actually worked Which product backlog items were completed, which were not completed Story points planned, story points delivered (i.e. velocity) Sprint burn down Impediments opened and closed Unit and acceptance test code coverage

148

Organizing the Project Memory

Project Wiki Additional documentation, e.g. deployment information, compliance evidence Impediments Holidays, people joining or leaving the project Logging important project information, e.g. Decisions Events Impediment backlog as a special case of logbook Visible for the team Source of insight for more general organizational impediments

149

Accounting
Recommended accounting procedure
The customer pays for sprints, i.e. the cost of the team for the sprint and receives an estimate of what can be delivered at the end of the sprint and receives the sprint result, i.e. the new product increment resulting from the completed product backlog items

Advantages
It is transparent There is no need to add a surcharge to cover the risk of a xed-price charge

150

Outside of Scrum
Time sheets
Most organizations need individual time-sheets They should not be connected to single tasks The sprint result is the achievement of the selforganizing team and not of the individual members

151

Example Sprint Burn Down

152

Example Release Burn Down

900" 800"

700"

600"
Remaining(Work((PT)(

500" Added"scope" 400" Original"scope"

300"

200"

100"

0" 0" 1" 2" 3" Sprint( 4" 5" 6"

153

Sprint Review

154

Goal of the Sprint Review

Making the project status transparent Presentation of the sprint results The product owner accepts or rejects results and gives feedback to the team Other stakeholders can add opinions Inspect and adapt at the sprint level

155

Participants
The Scrum team
The team presents results The product owner gives (positive and negative) feedback and accepts or rejects results The ScrumMaster moderates the meeting

All other stakeholders, interested customers and management

156

Preparing a Review
The team
Decides who is going to present what Prepares the demonstration

The ScrumMaster
Makes sure the sprint backlog and the burn down chart are up to date (on behalf of the team) Prepares an overview of the nished product backlog items and calculates the velocity based only on the nished items

The product owner

Should have the product backlog and the denition of done available to assess the presented sprint results

157

How to conduct a Sprint Review

The ScrumMaster opens the meeting The team presents the results
The stakeholders offer opinions and feedback The product owner accepts results The product owner records new ideas and insights and open issues to update the product backlog

The ScrumMaster states the velocity, recapitulates the insights, thanks all participants and announces the next meetings
Retrospective and sprint planning Date and venue of the next sprint review

158

What to do after a Sprint Review

The product owner updates the product backlog and prioritizes new features If necessary, the team estimates the size of the new features The team takes the insights to the sprint retrospective and recapitulates the lessons to learn

159

What a Sprint Review is Not

A motivational meeting A Powerpoint presentation A status report that does not paint a true picture of the current status A planning meeting A performance appraisal of individual team members Just a demo to a passive product owner

160

Scaling and Distributing Scrum

Scrum for Medium and Large Projects

161

What do we mean by Scaling?

A Scrum team is of size 7 2. Larger projects and complex products need several teams working in parallel Each team should have its own product owner and ScrumMaster In addition, there should be a chief product owner and a Scrum of Scrums master Scrum has been successfully scaled up to at least 500 participants. We have personal experience up to 150.
162

Brooks Law
Adding manpower to a late software project makes it later Throwing people at a problem will often not resolve the problem but make it worse Scale up organically and bear in mind that with a good Scrum implementation, teams can achieve more than you might assume with a traditional approach
You might not actually need to scale up as much
163

Start Small and then Grow Organically

Start small, with a single Scrum team This team can work on the basics for the initial sprints
Establishing the basic architecture ... and delivering some demonstrable functionality

Scale up by adding additional Scrum teams when this preparatory work has been accomplished and when necessary

164

Feature and Component Teams

Feature teams
Each team works on a different set of features or user stories Vertical slices of functionality

Component teams
Each team has ownership of one or more components

Both possible with Scrum but feature teams are the preferred option is most cases Integrating everything by the end of each sprint is much more difcult with component teams and might require an additional integration sprint which can be wasteful

165

Product Owner Team

Chief Product Owner

Product Owner Team A

Product Owner Team B

Product Owner Team C

Marketing

Customer

Customer

166

Product Backlogs
At the end of each sprint, update to reect the consolidated results of all teams

Product Owner Team A

Chief Product Owner Master Product Backlog

Team product backlogs updated just-in-time before synchronized sprint planning

Product Owner Team B

Product Owner Team C Team Product Backlogs

167

Scrum of Scrums

168

Scrum of Scrums
Enables teams to synchronize with one another during sprints Ideally daily, after the individual teams Daily Scrum, but 2-3 times a week often acceptable Representative from each team - not necessarily the ScrumMaster - the team decides dependent on the subject matter Three main questions:
What has the team done since the last meeting? What will the team do until the next meeting? What impediments does the team have that need to be escalated? (i.e. that cannot be efciently removed at the team level) Additional question: Is the team about to do some that will create an impediment for another team? (e.g. perform a large integration or fail to satisfy a dependency) Scrum of Scrums impediment log Logs and tracks issues that have been escalated to the Scrum of Scrums

169

Planning and Synchronizing

Synchronized sprint planning
All teams should begin and nish their sprints on the same day

By the end of a sprint, a team must have fully integrated its results with those of the other teams Regular Scrum of Scrums meeting
Basic method to coordinate the work of multiple teams

170

Recommendation: Synchronized Sprint Planning - 1

At the end of the previous sprint, each team should have its own sprint review and retrospective With 1-2 representatives per team present:
Each team gives a high-level review of progress during the previous sprint. Each team gets 15 minutes. Each team should also state what they need from other teams at the end of the sprint being planned (input dependencies), and what they understand that they must deliver to other teams at the end of the sprint (output dependencies).

171

Recommendation: Synchronized Sprint Planning - 2

The teams separate and carry out their own sprint planning (strictly time-boxed) If additional input dependencies or problems meeting output dependencies are identied during sprint planning, the teams should discuss and resolve during sprint planning After sprint planning, the representatives come together, briey discuss whether the input and output dependencies can be met and conrm the team commitments.
172

Distributed Teams
Scrum thrives on good communication
This is most effective if teams are collocated and can communicate direct face-to-face

If absolutely necessary, distribute teams geographically but avoid dispersing the members within each team Each team should have its own ScrumMaster and product owner The ScrumMaster must be collocated with the team It is desirable if the product owner is collocated with the team as well Consider cross-seeding the teams with team members from other sites on a rotating basis. This can help to break down cultural barriers and improve communication

173

Dispersed Teams
If you really have to disperse the members within a team:
Bring them together at the beginning of a project and regularly thereafter Use technology to increase the communication bandwidth (e.g. webcams, Skype etc.)

Team formation will take longer Productivity will never be as high as with a collocated team
174

Example: B2B Business Information System

Business information system (B2B) with web front end and very large data warehouse 4 feature-based Scrum teams, two in each of London and Stockholm Product owner team distributed across UK. Members regularly travelled to Stockholm Sprint reviews and planning meetings in London Sprint retrospectives local to each team Synchronized sprint planning in London with one representative from each Stockholm team physically present and others present via video conferencing
175

Example: Large CRM System

10 Scrum teams distributed between UK and India (> 100 people involved) Each team within itself collocated Component based teams An additional Scrum team decomposed user stories into component stories that were consumed by the component teams Daily Scrum of Scrums Synchronized sprint planning
176

Agile Retrospectives
Organizations Learn in Teams

177

Why Retrospectives
Share lessons learned Generate common insights Bring improvements back into the teams work
What worked well, what should be improved, what should we try

Uncover conicts Correct dysfunctional behavior

178

Retrospectives and the Organization

Learning in organizations takes place in teams Personal mastery is closely related to team learning and creating a shared vision Every project should be a strong learning experience
It is more fun It is effective for the team, it helps the team and its members to improve It is effective for the organization in the short and the long run

179

Retrospectives are about Learning

The purpose of a retrospective is to facilitate team learning Do not focus on mistakes but instead on learning and improvement Concentrate not on punishing weak performance from individual team members but on how to help them perform better Avoid assigning blame

180

When Should a Retrospective be Held?

After a sprint After an important milestone When conicts or important events occur At the end of a project

181

How Long is a Retrospective?

It depends - some proposals
After a 4 week sprint in a new team: 4 hours After the 5th Sprint with a low stress level: 2 hours At the end of a 12 moths project: 1 day

Different voices advocate longer or shorter retrospectives - nd what works for the team Dont skip retrospectives completely
The team will miss out on an important learning opportunity and important issues might remain hidden

182

Retrospective Blueprint
Open meeting State the purpose of the meeting, the agenda and the time box and agree discussion rules Gather data Collect observations and facts Generate insights Group facts, nd patterns and clusters, discuss underlying reasons and systematic structures Decide what to do Identify possible improvements, consequences in the work of the team and impediments Close meeting Find out if the meeting was worthwhile for the participants, thank them for their contribution

183

Who Should Attend?

The team The ScrumMaster The product owner (there may be exceptions, e.g. when there are conicts)
In some cases it is useful to split the retrospective, with the product owner present for part

The ScrumMaster moderates Others should only be present in exceptional circumstances and only when invited by the team

184

Generate Data: Timeline

185

Generate Insights: Cluster and Prioritize

186

Close Meeting: Return on Time Invested (ROTI)

187

Hints for ScrumMasters

Your rst retrospective will be a lot of work, but you will nd it easier subsequently. Dont skip them, it really pays-off: Retrospectives make good teams great. Build your toolkit There are lots of techniques to hold interesting retrospectives. Try something new to keep it interesting for your team. Observe how they work for you, the team, the situation and purpose. Collect feedback and evaluate it. Know your limits Some techniques are not easy to use or could uncover more than you can handle. If in doubt, ask an experienced colleague. Observe your limits and preferences. Be impartial When a retrospective uncovers a conict, be sure not to take sides. If in doubt, bring in a colleague.

188

Contact, Copyright and Attribution

189

Simon Roberts
BSc (Hons) in Physics MBA specializing in creativity, innovation and change Over 25 years experience in software engineering and project management Agile and light-weight methods since late 1990s Scrum since 2002 Experienced Scrum trainer, coach and mentor Certied Scrum Trainer, Certied Scrum Developer

190

Contact Information
ScrumCenter GmbH
training@scrumcenter.com

Simon Roberts
simon.roberts@scrumcenter.com Tel: +49 160 8082012

191

Copyright and Attribution

Except where otherwise noted: 2011 Simon Roberts and Christoph Mathis, all rights reserved.

The Scrum ow animation is taken from Mike Cohn: A redistributable introduction to Scrum http://www.mountaingoatsoftware.com/presentation/30-an-overview-of-scrum

192

ScrumCenter GmbH training@scrumcenter.com, scrumcenter.com

Version 2.2-en, May 2011 2011 ScrumCenter GmbH, All rights reserved