PRACTICAL SCRUM

Like us: www.facebook.com/PracticalAgile Visit: www.practical-agile.comFollow me: @LinkedinTweet: @PracticalAgile1

CONSTANT HIGHER MORE

LEARNING QUALITY FUN

Day 2

EXERCISE

Write 5 Multiple Selection Questions On Yesterday Material

Reminder: Agile Scrum (roles, ceremonies)

Transparency DoD

WasteLean Thinking

BEING AGILE IS OUR FAVORITE THING

What are we going to cover today?

TABLE OF CONTENTS5

21

35 56

60

87

90

What does it mean to be a product owner?

How to write requirements?

How to estimate stories

Long term planning in agile

What is the meaning of each ceremony in scrum?

How do we scale up?

Agile engineering Practices

PRODUCT OWNER (PO)• Defines the features of the product• Defines release dates and content• Responsible for ROI• Prioritizes feature according to value• Can change features and priority

once every predefined interval• Decides what will be worked on in

each iteration• Accepts or rejects results

EXERCISE

Painters Game

Round 1

Round 2

Round 3

SOUNDS FAMILIAR?

Traditionally throws content “over the fence”

The PO takes an active role throughout the development lifespan

Traditionally throws content “over the fence”

NO MORE! CONCEPT CHANGE

How? • Talk directly and frequently with your

customers

• Talk directly and frequently with your development teams

• Engage the development teams in creating value for your customers

• Maintain your product’s quality and agility – do not let technical debt accumulate

Manage the product Backlog 1. Clear2. Ranked

3. Optimize the value

4. Visible transparent

5. Ensure understanding

Sizing Requirements

Description Value Estimate Acc. test sprint Wiki link

As a …I would like to… so that 1200 3 1 www…..

As a …I would like to… so that 1100 5

Show successful login &

Show failing login1

As a …I would like to… so that 1000 3 1

As a …I would like to… so that 700 8 2

As a …I would like to… so that 10 8 2

... …

As a {persona/user} I would like to {do something} so that {achieve something} In order to {achieve something} as a {persona/user} I would like to {do something}

User Stories

Size

Priority

Best Before End Ep

ic

Independent Negotiable Valuable Estimate-able Short/Simple Testable

EXERCISE

Define 3 Users For A Social Network Special For Dog Owners

EXERCISE

Create a 2-3 PBI For A Social Network Special For Dog Owners

As a [user] I would like to [what]

So that [why]

Product Backlog Refinement = GroomingThe team and the PO together review the backlog in order to make it ready for the next 2-3 sprints

How?

Grooming = Clarifying, Estimating, and Splitting

Recommended to allocate ~5% of the sprint time

Splitting User StoryDifferent scenarios

Stubbing\mocking external dependencies

Splitting across the data model (e.g login only via username, no password)

Splitting across operations (e.g. delete & create, no update)

Splitting on results (e.g Success and failure scenarios)

Splitting cross-cutting concerns (e.g Security)

Splitting functional & non-functional requirements (e.g Scaling)

EXERCISE

Split The Biggest PBI

The terms and conditions to be met in order to accept a requirement as Done

ACCEPTANCE CRITERIA

GIVEN a pre-condition WHEN an action happens THEN an expected result occurs

Helps the team visualize what will it look like when it gets Done

•GIVEN login dialogWHEN user enters username=“Mickey” AND password=“Mouse”THEN user succeeds to login

•GIVEN login dialogWHEN user enters username=“Mickey” AND password=“Mouse”THEN user succeeds to login

•GIVEN login dialogWHEN user enters username=“Mickey” AND password=“TheMouse”THEN user fails to login

•GIVEN login dialogWHEN user enters username=“Mickey” AND password=“Mouse”THEN user succeeds to login

•GIVEN login dialogWHEN user enters username=“Mickey” AND password=“TheMouse”THEN user fails to login

•GIVEN login dialogAND login_type=“secure”WHEN username=“Mickey” AND password=“Wrong” WHEN submit WHEN submit THEN user is blocked

EXERCISE

Write 2-3 Acceptance Criteria For The Highest PBI

Given… When… Then….

Agile Effort Estimations

EXERCISE

Estimate The Following Based On Weight In Kilograms [No Google Please!!!]

• Chihuahua • Great Dane • Staffordshire bull terrier • Appalachian mountain dog • Border Collie • American Cocker spaniel

“IT IS BETTER BE ROUGHLY RIGHT THAN PRECISELY WRONG”John Maynard Keynes

Persistence of Time

34.4

Relative Estimations

• We are: - Not good in measuring absolute values- Good in comparing things

• We have the basic math skills (or a calculator)

• High accuracy has a high toll

• Estimates become commitments

• Time is not persistent

Why Relative?

Story Points:

They reflect the “bigness” of a user storyHow hard it is ? How risky it is ? How much of it there is ? 5

?

3

1. Each person gets a deck of cards (Fibonacci)

2. The item to be estimated is read to all

3. Attendants ask clarifications for the item

4. Each person selects a card and puts it on the table facing down

5. When everyone is done, cards are exposed

6. If the estimations do not match a short discussion is done:Highest and Lowest estimators speak first -> return to step 4

7. Handle next item

Planning Poker:

EXERCISE

Estimate The Following Based On Size Using Planning Poker

• China • Luxembourg • Denmark • South Africa - 8 (Reference

point) • Belize

• Those who do the work estimate it

• Emphasizes relative estimation

• Estimates are within one order of magnitude

• Modeled for open discussion – forces thinking

• Reduces anchoring - Everyone's opinion is heard

WHY USE PLANNING POKER?

One page specGroup A

7 Pages specGroup B

173 hours

117 hours

Specification Length

Group A

added irrelevant details:•End user desktop apps•Usernames & passwords•Etc

Group B

39 hours

20 hours

Irrelevant Information

Requirements 1-4

Group A

Requirements 1-5Group B 4 hours

4 hours

Requirements 1-5 but told to estimate 1-4 only

Group C8 hours

Extra Requirements

Group A

Customer thinks 500 customer has no technical knowledgeDon’t let the customer influence you

Group B555 hours

456 hours

Same as B customer thinks 50

Group C99 hours

Anchoring

WHY USE PLANNING POKER?

IT IS QUICK!

IT IS FUN!

Spain 3

China Too big

Luxembourg 0

Denmark 1

South Africa 8

Belize 1

Chihuahua 3

Great Dane 90

Staffordshire bull terrier. 17

Appalachian mountain dog.

???

Border Collie 34

American Cocker spaniel 13

The Results

Velocity = Speed + Direction How many points can the team complete in one iteration

Easy to measure

Fixes estimation errors

Easily reflects the project status

Primary parameter in planning

SP 8

priority

5

priority

4

SP 8

priority

3Planning

Iteration Planning

As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration

SP 5

priority

2Planning

SP 2Iteration 1:

SP Done = 5+8+2 = 15

velocity = 15

SP 8

priority

5

priority

4

SP 8

priority

3Planning

Iteration Planning

As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration

SP 5

priority

2Planning

SP 2Iteration 1:

SP Done = 5+8+2 = 15

velocity = 15

priority

7

SP 5

priority

6Planning

As Elad, product owner, I would like to calculate team velocity so that I will be able to estimate how much work we are going to complete in two months

SP 8

priority

5Planning

SP 2Iteration 2:

SP Done = 8+5 = 13

velocity = (15+13)/2 = 14

SP 5

priority

8

What will happen if support is needed?

SP 2

priority

7

Long Term Crisis:

Planning

Iteration 3:

SP Done = 2+5 = 7

velocity = (15+13+7)/3 = 12 ~

SP Done:

Iteration 4 = 5

Iteration 5 = 7

Iteration 6 = 6

Velocity = (13+7+5) = 8

Velocity = (7+5+7) = 6

Velocity = (5+7+6) = 6

Planning For Support: Alternating team each sprint

Alternating person each sprint

Limiting the hours per team

Use velocity - Ignoring it completely

Agile Planning With Scrum

Daily

Iteration

Release

Product

Portfolio

Strategy

Release Planning #Story

points

Time

Velocity

Calculating Release Time

Given that:

The items for the release are estimated

The velocity is known (or predicted)

We know the scope or deadline

#Story

points

Time

Velocity

Calculating Release Time

We can estimate:

How much content can we do until the deadline

How many sprints it will take to complete the content

# Sprints X Velocity = # Story Points

# Story Points

Velocity = # Sprints ____________

#Story

points

Time

Velocity

Scrum Ceremonies

Sprint PlanningThe first meeting of the sprint

Length: 2-8 hours

Participants: PO, Team, Scrum Master

Preconditions: Product backlog should be in good shape

Divided into two parts

Sprint Planning Goal

Sprint Planning - Part IDecide what the team takes to part II

1. PO Explains the top items from the backlog

2. Team decides what takes to part II in order to commit for sprint content

3. Team and PO selects the sprint goal

Sprint Planning - Part IIGenerate the sprint backlog & commit on the sprint’s content

How?Splitting each of the stories into smaller tasksEstimating each task (maximum length 8 hours)Design decisions Verify that the goal is achievableCommit

Sprint Backlog

The sprint Backlog Belongs to the teamAssists the team in tracking the sprint’s progressMaximum task length should not exceed 16h (2 days) for a 2 week sprintUpdated throughout the sprint• Every team member can add, remove or change the sprint backlog• Status of tasks & remaining work is updated daily• Sprint content emerges

To do In progress Done

PBI # 1

PBI # 2

Task Board

To do In progress Done

PBI # 1

PBI # 2

Task Board

To do In progress Done

PBI # 1

PBI # 2

Task Board

To do In progress Done

PBI # 1

PBI # 2

Task Board

To do In progress Done

PBI # 1

PBI # 2

Task Board

Burndown Chart

A simple visual way of tracking progress

Used in different levels:SprintReleaseProduct

Shows the amount of work left to reach target

Effo

rt re

mai

ning

0

25

50

75

100

Sprint

1 2 3 4 5 6 7 8

Release Burndown Chart

Daily Scrum

Every day, Same time, Same time

No longer than 15 minutes

Stand up

All the team must attend

Only team members are allowed to speak

Daily

Daily

3 Questions: 1. What have we accomplished since the last daily

2. What will we complete until the next daily

3. What are my/our impediments

Sprint Review

Show & Tell

Bazar Review

Close the sprint

Participants: The team, PO, everyone (managers, customers..)

Inspect & adapt, focus on feedback - this is NOT a Demo

Focus on shard learning - not reporting

Only Done Working Software allowed

Avoid power point presentation

Sprint Review

EXERCISE

Ball Point Game

EXERCISE

Ball Point Game

‣‣‣‣

Sprint Retrospective

‘The greatest enemy of great is good enough’

Goal: Inspect and create plan for improvements Team time tune & adjust After sprint review - Before sprint planningLength: 1-2 hoursParticipates: Scrum Master and the team (others are optional)Generate AI (experiments) to execute the following sprint

Sprint Retrospective

Things to Stop doing

Things to start doing

Things to Keep doing

Retrospective Model Example

Opening (2-5 minutes)

Data collection (15-25 minutes)

Generate insights (15-25 minutes)

Decide what do do (15-25 minutes)

Closing (2-5 minutes)

THE WRONG WAY TO DO RETROSPECTIVE

LeSS - Large Scaling Scrum

The basic assumptions

(just like scrum…)

For large groups, LeSS hits the sweet spot between defined concrete elements and empirical process

control.

There are no best practices. Only good practices within a specific

context

Engineering PracticesPair programming

Refactoring

TDD \ ATDD

Continuous integration

Pair Programing A technique used to:

Increase quality level (code review is built in)

Increase knowledge sharing

Over time increase productivity

RefactoringGoal: Improve readability while preserving meaning

Refactoring ≠ Redesign

Does not fix bugs

Done as a series of steps, each step does a little

Refactoring is not a “standalone” task

Most modern IDE’s have auto-refactoring tools

Test First / TDD - ATDDTDD – Test driven development:

A Design technique

Never write a line of code unless it fixes a failing test

Red -> Green -> Refactor

ATDD – Acceptance TDD:

A Requirements management technique

Requirements are written as functional tests

Usually with tools such as Cucumber / SpecFlow

For every failing functional test run the TDD cycle

Continuous Integration

1. The system is always integrated (even multiple sites\ multiple components)

2. CI systems can and should be aggregated

3. Requires check ins as often as possible

Usually done by a system that automatically:

Generates a new build version

Runs all unit tests

Creates a deployable package

Installs it to production equipment

Runs all system tests

Run LSP tests

Publishes results•

Parking lot

“THE VALUE OF AN IDEA LIES IN THE USING OF IT”

Thomas Edison