57
Zen of Scrum

Zen of Scrum

Embed Size (px)

DESCRIPTION

Introduction to Scrum: a product development framework based on agile principles.

Citation preview

Page 2: Zen of Scrum

Agile Manifesto

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

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

Page 3: Zen of Scrum

Scrum Goals

Deliver working (“potentially shippable”) software frequently by developing functioning software in each iteration

Favor customer collaboration by encouraging customer involvement throughout the project

Respond to changing requirements, even late in development, by not planning ahead in too much detail

Avoid procrastination, or ”student’s syndrome”, by working in small increments

“Scrum employs an iterative, incremental approach to optimize predictability and control risk.”

- Scrum Guide

Transparency

Work

Inspect

Adapt

Page 4: Zen of Scrum

Scrum Values

Courage Respect Focus

Commitment Openness

Page 5: Zen of Scrum

Scrum Distilled

Product backlog Increment

Team

ProductOwner

SprintPlanning

DailyStand-Up

SprintRetrospective

Release2-6 months

Sprint2-4 weeks

Daily Scrum24 hoursScrum

Master

Sprint backlog

scrum team iterations events

SprintReview

Page 6: Zen of Scrum

Scrum Team

“Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback.”

- Scrum Guide

ProductOwner

ScrumMaster

Team(Developers)

Responsible for Product Backlog (PBL)

Ensure developers understand PBL items

Maximize ROI

Ensure Scrum is understood and enacted

Scrum coach Removing impediments Facilitate meetings

Deliver potentially releasable increment of “Done” product at the end of each Sprint

Self-organizing Cross-functional

“…designed to optimize flexibility, creativity, and productivity.”

- Scrum Guide

Page 7: Zen of Scrum

Definition of Done

It is crucial to have the same definition of done in the Scrum team, between teams, across the organization, and when talking to other stakeholders and customers. Everybody must understand what “done” means Helps during estimation Ensures transparency Helps to avoid technical debt “As Scrum Teams mature, it is

expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.”

- Scrum Guide

Page 8: Zen of Scrum

Planning and Estimation

http://www.flickr.com/photos/calypso/2767592937/

Page 9: Zen of Scrum

Product Backlog

Ordered list of everything that might be needed in the product

Single source of requirements Dynamic

“The Product Backlog is often ordered by value, risk, priority, and necessity. Top-ordered Product Backlog items drive immediate development activities. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value.”

- Scrum Guide

Page 10: Zen of Scrum

User Stories

123

5 points

As a ...

I want to ...

So that I can ...

Story XYZ

Page 11: Zen of Scrum

User Stories

INVEST in the user stories Independent – avoid dependencies on other stories Negotiable – stories are not a contract Valuable – show the value to customers/stakeholders Estimable – sufficient detail needs to be present Sized right – small enough to complete in one sprint Testable – Acceptance criteria should be apparent in story

Page 12: Zen of Scrum

Estimation Key Points

It’s easier to estimate relatively than absolutely It’s difficult impossible to accurately estimate calendar time Firmly establish estimates by team commitment Separate the task of estimating size and duration Only re-estimate relative changes

Page 13: Zen of Scrum

Cone of Uncertainty

Project evolvement

estim

ation

acc

urac

y

1x

4x

2x

0.5x

0.25x

Page 14: Zen of Scrum

Story Points vs Ideal Days

Ideal days are easily confused with calendar time, especially when communicating outside the team

My ideal day is not your ideal day Ideal days always have a relationship to calendar days. If the

project takes twice the ideal days in calendar time to finish, it does not mean the team is 50% efficient

If everything takes longer (or shorter, even though longer is much more common :-P) you do not have to re-estimate; this is more intuitive using story points

Page 15: Zen of Scrum

Estimating with Story Points

Page 16: Zen of Scrum

Estimating with Story Points

2

2

1

53

Page 17: Zen of Scrum

Story Points

0 1 2 3 5 8 13 20 40 100Stories Epics

Page 18: Zen of Scrum

Story Points

0 x 8 ≠ 0

Page 19: Zen of Scrum

Story Points

XS S M L XL

Page 20: Zen of Scrum

Poker Planning

012835 8102040100

Page 21: Zen of Scrum

Story Splitting

Story 1

123

5 points

Story 1

123

Sometimes stories are too big for one sprint Story Splitting Patterns

Boundaries: Operational, data, interfaces Remove cross-cutting concerns: Logging, Exception handling, ... Functional and non-functional aspects Business value

Anti-Patterns When in doubt,

do a spike solution

Page 22: Zen of Scrum

The Sprint

http://www.flickr.com/photos/john_scone/493915787/

Page 23: Zen of Scrum

Sprint Planning

Agenda Select user stories Identify and estimate

technical tasks Come up with sprint goal

Participants Product Owner Scrum Master Developers

Two parts: (a) Selecting stories and (b) identifying tasks. The PO and stakeholders only need to participate in the first half, but must still be available during the second half.

Page 24: Zen of Scrum

1 hrs

Story 1 123

5 points

4 hrs

1 hrs

2 hrs

4 hrs

8 hrs

Sprint Planning

Page 25: Zen of Scrum

Product Backlog Grooming

Agenda Update the product

backlog Refine and split top stories Estimate stories

Participants Product Owner Scrum Master Developers

Page 26: Zen of Scrum

Sprint Rules

No changes affecting the Sprint goal No changes to team Scope may be discussed, re-negotiated and clarified

as knowledge is gained

Page 27: Zen of Scrum

Sprint Emergency Procedure

1. Can anything be changed in the way work is done?

2. Can anyone outside the team help?

3. Can something be dropped from the sprint backlog?

Three questions to ask before canceling a sprint:

Page 28: Zen of Scrum

Sprint Length

Size matters. Shorter is better! Feedback more often Stable velocity quicker React to changes faster Learn processes faster ”If it wasn’t for the last minute, nothing would ever get

done.” - a lot more last minutes

Page 29: Zen of Scrum

Daily Stand-Up Meeting

Agenda What has been accomplished

since the last meeting? What will be done before the

next meeting? What obstacles are in the

way?

Participants Scrum Master Developers Passive: Other interested

parties - only listen!

Same time and place every day. Only answer the three questions, keep any discussions outside the meeting. Instead, meet immediately after the Daily Scrum for re-planning and further discussions.

Page 30: Zen of Scrum

Sprint Backlog

TO DO IN PROGRESS ”DONE”

UNPLANNED

NEXT

STORY

Story 1 123

5 points

Story 2 127

1 points

Story 3 213

8 points

5 points

5 points

Story 4 129

3 points

BURNDOWN CHART

Definition of Done

SPRINT GOALImplement a working API

Page 31: Zen of Scrum

Sprint Backlog

TO DO IN PROGRESS ”DONE”

MN

STORY

Story 1 123

5 points

Story 2 127

1 points

Story 3 213

8 points

SA

PL

BURNDOWN CHART

UNPLANNED

NEXT

5 points

5 points

Story 4 129

3 points

SPRINT GOALImplement a working API

Page 32: Zen of Scrum

Sprint Backlog

TO DO IN PROGRESS ”DONE”

MN

STORY

Story 1 123

5 points

Story 2 127

1 points

Story 3 213

8 points

SA

PL

PL

SA BURNDOWN CHART

UNPLANNED

NEXT

5 points

5 points

Story 4 129

3 points

SPRINT GOALImplement a working API

Page 33: Zen of Scrum

Sprint Backlog

TO DO IN PROGRESS ”DONE”

MN

STORY

Story 1 123

5 points

Story 2 127

1 points

Story 3 213

8 points

SA

PL

MN

SA BURNDOWN CHARTMN

PL

PL

SA

UNPLANNED

NEXT

5 points

5 points

Story 4 129

3 points

SPRINT GOALImplement a working API

Page 34: Zen of Scrum

Sprint Backlog

TO DO IN PROGRESS(2)

”DONE”

MN

STORY

Story 1 123

5 points

Story 2 127

1 points

Story 3 213

8 points

SA

PL

PL

SA

TESTS COMPLETE

HOURS

32

8

48

Page 35: Zen of Scrum

Sprint Burndown ChartH

ours

Days

Page 36: Zen of Scrum

Sprint Review

Agenda What has been done,

what has not been done What went well, any

problems Product backlog What to do next

Participants Product Owner Scrum Master Developers Stakeholders

Page 37: Zen of Scrum

Sprint Retrospective

Agenda Inspect last sprint

People and relationships Process and tools

Identify potential improvements

Plan for implementing improvements

Participants Scrum Master Developers

Page 38: Zen of Scrum

Release Planninghttp://www.flickr.com/photos/acediscovery/3030548744/

Page 39: Zen of Scrum

Agenda Goal for the release Identify features Rough estimates Create a release plan

Participants Product Owner Stakeholders Scrum Master Developers

Release Planning

Page 40: Zen of Scrum

Release Planning

Can Have

Might Have

Won’t Have

X weeks

Fixed Date Fixed Scope

Page 41: Zen of Scrum

Release Burndown ChartSt

ory

Poin

ts

Sprints

Page 42: Zen of Scrum

Release Burndown Bar ChartSt

ory

poin

ts

Sprints

Team ProgressCompleted storiesRe-estimations

Workload changesAdded featuresRemoved features

Page 43: Zen of Scrum

Theme, subsystem, product

Parking Lot Diagram

Sprint 8

Theme, epic, feature set

(8)

50%

Theme, subsystem, product

Sprint 3

Theme, epic, feature set

(8)

50%

Sprint 10

Theme, epic, feature set

(8)

0%

Sprint 8

Theme, epic, feature set

(8)

50%

Theme, subsystem, product

Sprint 3

Theme, epic, feature set

(4)

25%

Sprint 12

Theme, epic, feature set

(8)

0%

Sprint 12

Theme, epic, feature set

(4)

0%

Page 44: Zen of Scrum

Scaling Scrumhttp://www.flickr.com/photos/28481088@N00/2957770391/

Page 45: Zen of Scrum

Scrum of Scrums

Page 46: Zen of Scrum

Scaling Scrum

Synchronize sprints between teams Do integration at sprint boundaries

Coordinate work Lookahead planning

Complexity increases

Page 47: Zen of Scrum

Distributed Scrumhttp://www.flickr.com/photos/darkroses/2357927668/

Page 48: Zen of Scrum

Distributed Scrum

Shared vision and goal Personal relationships

Kick-off meeting Workshops

Same standards and values Estimation Definition of Done

Tools for distributed collaboration Virtual Scrum boards Video conferencing Screen sharing

To be successful...

Page 49: Zen of Scrum

Distributed Daily Stand-Up Meetings

Time

Team

A

BWorking Hours

Working Hours

Page 50: Zen of Scrum

http://www.flickr.com/photos/droetker0912/5542920908/

Additional Stuff

Page 51: Zen of Scrum

Scrum Misconceptions

Scrum says documentation isn’t important.” Documentation is important, but

working software is valued more.!People need to be ”cross-functional”. That sounds both inefficient and unrealistic.

” Teams need to be cross-functional, not people.

Nonetheless, it is always a good idea not to rely on one person.

Spread the knowledge.

!

Page 52: Zen of Scrum

Scrum Misconceptions

We can’t estimate in size, I need to know when we can deliver.” Using story points you can still

estimate when the project will be completed. The important

difference is that duration is derived from size.

!It’s not possible to mix Scrum and our traditional project model (read: waterfall)” Maybe you will not reach Scrum’s

full potential, but you can benefit from agile methods nontheless.!

Page 53: Zen of Scrum

Scrum Misconceptions

We’re working on a fixed price contract, so we can’t use Scrum.” Let the project manager act as

product owner, and use Scrum inside your organization.!

Scrum does not work with distributed teams.” Good point. Co-located teams are

always best, but it is possible to use Scrum in a distributed

organization as well.!

Page 54: Zen of Scrum

Scrum Misconceptions

When you split stories you create dependencies, but you should INVEST in the user stories? (Stories should be independent)

” Stories should independently bring value to the product. They

can still have logical dependencies on other stories.

Remember: the product backlog is ordered.

!

Page 55: Zen of Scrum

Supporting Practices

XP practices Sustainable pace Collective code ownership Test Driven Development (TDD) Continuous Integration (CI)

Meeting Techniques Preparation Time boxing

Pragmatic Programming

Pair programming Coding standards Refactoring Spikes

Page 56: Zen of Scrum

Further Reading

Devoted Developer – www.devoteddeveloper.com The Scrum Guide - www.scrum.org

”Agile Estimating and Planning”, Mike Cohn, 2005 Addison-Wesley - www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning

User Story Primer - trailridgeconsulting.com/files/user-story-primer.pdf

Scrum Alliance - www.scrumalliance.org/

How to Split a User Story - rslawrence.wpengine.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Page 57: Zen of Scrum

Time’s up!