certiﬁed - scrum sense · estimation meeting: formal capture and sizing of new backlog items....

ScrumMaster

Certified

Peter Hundermark

1Friday 09 April 2010

day 1 | 08:30 - 17:00

getting going


day 1 | season 1 | 08:30 - 10:00

Spaghetti The power of self-organisation


* How did it feel as a team member waiting to be told what to do?[20]


Introductions* pair-up (1 minute each way)* introduce each other

www.scrumsense.com


Scrum Sense* 2007* 3 Agile coaches* Scrum rollouts, XP practices, Kanban visual management


Let’s gather a list of questions and issues you’d like to resolve...


My goals:* Know what Scrum is...and is not* Understand your role* Realise Scrum is not a silver bullet* See the world a little differently

course documentwww.scrumsense.com


* Slides will be available from web site (password protected)* All participants will get a copy of “Do Better Scrum” booklet.

timetable08:30—12:0013:00—17:00


* Tea & coffee from 08:00* Tea breaks around 10:00 & 14:30* Toilets are...

RULES10Friday 09 April 2010

* Cell phones off during class* One conversation* Be on time* Change tables/seats after exercises/breaks

Deliver Ball Points

As a group, delivery as many ball points as possible:

2 minutes to plan

5 sprints of 2 minutes each

2 minutes between sprints to improve process

Rules:One team - all members participate

Score 1 point when every person has touched the ball (at least once)

Pass one ball at a time

Don’t pass to person next to you

Ball must have “air time”

No limit to balls in play

Dropped balls are bugs and may not be re-used in current sprint

Developed by Bo!s Glo"r


Reflect:* What happened?* Which sprint felt best?* Did you adapt your process?* Why, or why not?[30-40]

agile principles


day 1 | season 2 | 10:30 - 12:00


Common problems: * Releases take too long | Stabilisation takes too long | Changes are hard to make | Quality is falling | Death marches are hurting morale* This led to thought leaders collaborating on “lightweight” process solutions…


Hand out a copy of the Agile Manifesto plus 12 principles.


Defined process control* Given a well-defined set of inputs, the same outputs are generated every time.* A defined process can be started and allowed to run until completion, with the same results every time.* A defined process control model requires that every piece of work be completely understood.


Empirical process control* Achieves control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.* Permits emergence—requirements, solution design, etc.* Observation: impossible to map a defined process to an empirical process model.

Scrum is an empirical process framework for managing development and deployment of complex products.


...So we can now define Scrum as...

Empiricism is dependent on frequent inspection and adaption to reach a goal.


Everything is made visible Transparency


Inspection is dependent on transparency.


Self-organisation requires trust.Trust is only possible when team members feel safe.


Feeling safe depends on respect...respect for ourselves and offering respect to each other.


Collocated, cross-functional team

Empirical process modelScrum Flow


This is the Shewhart or Deming Cycle, which is a famous example of an empirical process modelCan you relate this to the Ball Points game we played earlier?

Events and ArtefactsScrum Flow


Every event in Scrum is time-boxed. This helps to keep everyone focussed on meeting the Release and Sprint goals.Remember:* Pareto principle: 80% of the value can be achieved with 20% of the effort or time.* Student syndrome: optimism and procrastination leads to late delivery.* Parkinson’s Law: work expands to fill the time available to do it.

scrum roles


day 1 | season 3 | 13:00 - 14:30

Trust Line Win-lose or win-win?


* Create a (long) line on the floor using masking tape* People pair up on opposite sides of the line* To win you must persuade your opponent to cross the lineBoth members of each pair simply step across the line for a win-win solution.Learning: We are programmed for win-lose. Collaboration is about win-win, not win-lose!

A role is a collection of responsibilitiesRoles and Responsibilities


Role in a Process NOT a Position in an Organisation

Exercise: Scrum Roles

Form 3 teamsEach team writes down responsibilities for 1 role on flip chart paperSwap papers between teamsSwap once more


Allow 5 minutes for each team to work on each role. Then review in conjunction with the following slides…

Product Owner

Responsibilities

Working on a shared vision

Gathering requirements

Managing and prioritising the Product Backlog

Accepting the software at the end of each iteration

Managing the release plan

The profitability of the project (ROI)


Metaphor: Entrepreneur

Team

Responsibilities

Estimating size of backlog items,

Committing to increments of deliverable software

– and delivering it.

Tracks own progress.

Is self-organising – but accountable to the Product Owner for delivering as promised.


People who do the work

ScrumMaster

Responsibilities

Empowering and shepherding the team,

Removing impediments,

Keeping the process moving, and

Socialising Scrum to the greater organisation


Metaphors: Robin Hood; sheep dog (! sheep)Servant leader and facilitator dealing with:* Tyranny of waterfall* Illusion of control* Belief in magic* Era of opacity

What kind of problems do you get if the ScrumMaster is part of the development team?


1. What are some of the challenges a ScrumMaster would have if he/she was also a member of the team?2. Are there any conflicts?3. If there are conflicts, can one person cope with them?Discuss at your tables (5 min)Feedback (1 min per group)

The Scrum Team

Product Owner

Team Members (Scrum Development Team)

ScrumMaster


Scrum Team = PO + SM + Scrum Development Team (or Scrum Delivery Team)

Roles Outside the Scrum Team

Customer $

User—of the product

Manager


Exercise: Roles I

Internet portal company

5 Product Owners: News, Email, Products, Security, Infrastructure

1 Scrum Development Team (9 people)

Want 1 integrated portal product

No delivery after 7 months

You have been appointed as ScrumMaster.

What improvements can you suggest?


Allow 5 minutes for discussion in teams, then 1-2 minutes each for their ideas.

Exercise: Roles II

They have implemented your suggestions and appointed a single Product Owner, David.

It is now the Sprint Planning Meeting and David presents his own Backlog.

After 3 hours and 55 minutes of bickering, the Product Owners are nowhere.

What do you do?


Allow 5 minutes for discussion in teams, then 1-2 minute each for their ideas.Emphasise ScrumMaster role is to keep the process moving. This is why we say the team execute on the backlog presented by David!

scrum meetings


day 1 | season 4 | 15:00 - 16:30

Estimation Meeting

Preparation for Sprint Planning

Formal estimation

Have at least two meetings per Sprint

Estimate only Size not Time

Provides input for Release Planning


Estimation Meeting: Formal capture and sizing of new backlog items.Purpose: Preparation for Sprint PlanningSolves the requirement that you have to have always a prioritised and estimated backlog, and the upcoming backlog items are sufficiently small to complete several within one sprint. (Why?)Our experience is that you should have 2 meetings per sprint. Not longer than 90 min. each.Everyone, especially the Product Owner, brings new Backlog Items. Development Team does the estimation.Only size of Backlog Items will be estimated - not duration.Estimation meeting also creates the input for the release planning.Who schedules these meetings? Who attends? Does the PO estimate?If the Product Backlog is not ready for Sprint Planning, the team goes to the beach!

Sprint Planning Meeting (part 1)

Product Backlog

Team capabilities

Business conditions

Technology stability

Executable product increment

Sprint Goal

Selected Product Backlog

Review

Analyse


Purpose of SP1: Commit to Product Backlog for the next Sprint

Analysis workshop during which team understands the requirements in order to be able to commit to the Product Owner as much Product Backlog it believes it can turn into a “done” increment in the next Sprint.

* Attended by Scrum Team plus anyone else whom they need to provide input.* ScrumMaster must ensure team knows its net capacity for the Sprint (allowing for planning meetings, leave, etc.)* Realistic commitment relies on team having a clear definition of done.* Output is the Sprint Goal and the Selected Product Backlog.* Time-boxed (4 hours for a 4-week sprint)

Sprint Planning Meeting (part 2)

Sprint Goal

Selected Product Backlog

Analyse

DesignSprint Backlog


Purpose: For the team to figure out what it is going to build and how it is going to build it.

This should start with design work…what is the design for the Backlog items the team committed to? Then the team figures out how it will develop the design, which translates into the work the team will perform = the Sprint Backlog.* Attended by the development team and SM; PO (and others) must be on call to answer questions. The PO’s role is to clarify and make design trade-off’s.* Product Backlog may be de-committed or additional Product Backlog requested by the team.* Tasks on the task board are NOT THE OBJECTIVE of SP2, only a final outcome.

Time-boxed (4 hours for a 4-week sprint)

Using the Task Board


Demonstrate using a flip chart

Daily Scrum MeetingsDaily 15 minute meetingSame place and time every dayTeam room - with task boardChickens and pigsThree questions:

What have you ACHIEVED since last meeting?What will you ACHIEVE before next meeting?What is in your way?

Impediments andDecisionsOne of three ‘inspect and adapt’ points in Scrum


One of three main ‘inspect and adapt’ points in the Scrum flow.

Monitoring progress Burndown charts


Sprint burndown: hours, tasks or story points? who updates? Draw an example...Release or product burndown? who updates? Draw an example...Impediment list / backlog: who maintains this? Draw an example…

Sprint Review

Done!

Another of three main ‘inspect and adapt’ points.Attended by the Scrum Team + all interested stakeholders.Review Selected Product Backlog.Show built (done) functionalityGroom Product Backlog based on outcome of Sprint and conversationSet next Sprint goal


Each Sprint MUST deliver some business functionality:* to prove the architecture works* to prove to the customer that work they care about is taking place, and* as a basis for estimation

Sprint Retrospective

Team meets with Scrum Master to inspect and adapt their process

Team devises solution to one or two most vexing problems


The third main ‘inspect and adapt’ point


day 1 | retrospective | 16:30 - 17:00* what will I tell someone I meet tonight?

ScrumMaster

Certified

Peter Hundermark


day 2 | 08:30 - 17:00

practices1


season 5 | 08:30 - 10:00

what puzzles you?


review of day 1?[10-20]

Go!50Friday 09 April 2010

[10-15]

HEARTBEATRETROSPECTIVES

Learning from the past for the future


[30-40]

Storytelling


The Secret of Gravity


Disappointment of Expectations54Friday 09 April 2010

stops Learning!Blaming


1 2

4 5

3

6


-- Norman Kerth , Project Retrospectives

“Regardless of what we discover, we understand and truly believe: that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”


Timeline telling the tale


What Went WELL?59Friday 09 April 2010

Significant events for youTell a short story about every eventPutting it on a flip-chart detachesThe Story becomes a part of the team history

IMPROVE!60Friday 09 April 2010

SCRUMMASTERTEAM MEMBER

PRODUCT OWNERORGANISATION


SORTINGPRIORITISING

RANKING


INPUT FOR SPRINT PLANNING


Develop action plans for 1-2 highest priority items team would like to improve...take these into the next sprint planning (add to backlog).

less than 90 min!


NØT IN THE TEAM ROOM


everybody the team invites


sizingthe backlog


Affinity-based sizing, using currency sizes = 1, 2, 5, 10, 20, 50)[20-30]

Sizing Estimate dog points

• Chihuahua• Great Dane• Golden

Retriever

• Poodle• Newfoundland• Australian

Guildenbaur


Chihuahua - estimates should be small (1-2?)Great Dane - estimates should be very large (20+?)Golden retriever - medium to large (5-13?)Poodle - do we mean ‘standard’ or ‘toy’? (3- or 8+?)Newfoundland - unknown? (20+??)Australian Guildenbaur - does not exist!Learning: Quick, accurate/consensus, fun![10]

Why estimate size?


All measurements are relative to a standard or scale.Standards are simply agreements between people - e.g. metre standardWe use size as a measure of complexity of one item (feature) relative to another.Why not use time? Scrum is results-oriented, not effort-driven!We use a Fibonacci sequence. Why?Our units are Story Points...could be ping-pong balls...anything but time!All measurements are subject to error or uncertainty.We value consistency over accuracy.[5]

Velocity


Velocity = size / time = Story Points per SprintVelocity is a real measure of what the team produces each Sprint...provided the team stays true to its definition of done! (More on done later in the course…)The only purpose of velocity to do release planning. It is not a tool to whip the team!Velocity is self-correcting.My team’s velocity ! your team’s velocity (unless we synchronise our estimations).It takes 3 Sprints to get an idea of the team’s velocity. So how do we start off?ScrumMaster asks for team’s commitment story by story![5]

practices2


season 6 | 10:30 - 12:00

The development team owns qualityDone!


We need to talk about the meaning of “done” and its importance in the Scrum framework…[40]

Building the Thing Right

More time to implement

Solid engineering practices

Solid engineering infrastructure

XP practices


Compare with the PO’s Product Backlog, which is focussed on building the “right thing”. We need both…

To do this requires sufficient time and good development practices!

Definition of “Done”

Team + Product Owner define

Defines current technical capability of team

Over time should include everything needed before deployment

Not done backlog items should not be demonstrated

Planning

Analysis

Architecture, Infrastructure

Coding

Design

Testing

Performance

User Acceptance

Pilot

Live


It is one of the ScrumMasters duties to stop the development team from demonstrating backlog items that are not done! This may lead to tension between the team and the SM and/or the PO and the SM.

Ultimately the SM is protecting the team from both a too-pushy PO and from its own muscle memory of unprofessional work habits!

And she is ultimately protecting the organisation from design-dead products!

Exercise: Done

Discuss at your table:

What does “done” mean in your current project?’

What issues do you see with this definition of done?

How would you address them?

What engineering problems do you see with this approach?

How would you rectify them?


10 minutes at your tables. 5 minutes feedback.[15]

“Undone” work

Create Product Backlog Items for “Undone Work”

Plan

ReviewPlan

ReviewPlan

ReviewPlan

Review

Review

Plan

Release? Release

Undone Undone Undone Undone

Stabilization Sprint


“Undone” refers to work that must be completed prior to any release.“Undone” work grows every Sprint, as the proportion of Sprint undone / Sprint done.It must be added to the Product Backlog and must be completed prior to any release.

Core Functionality

Aka infrastructure and legacy software

Most significant new functionality builds on it

Is fragile, doesn’t have test harnesses, and few people still know how to or are willing to touch it

Requires more time to work on


The few people, if any, who do know it are also scarce and valuable people whose time and expertise would much better be spent elsewhere. Such people also become overworked, frustrated and demotivated. Ultimately they leave the organisation, which makes the situation even worse.

Core Functionality

Time65 7

Requirements, Product Backlog

Where does core functionality come from?Is it bought from a malicious competitor?

...1


Unfortunately, we did this to ourselves, by not following good engineering practices like re-factoring, and allowing ourselves to be beaten up by managers who don’t understand how software needs to be built.

Note that the final line can actually trend upwards, implying that the functionality of the product is reduced. We are breaking more functionality than we can fix or add!!

Exercise: Core Functionality

Planned work consists of:

Function 1: 20 units of work, 15 new, 5 core



Velocity for new functionality is 15 units of work per Sprint.

Velocity for core functionality is 5 units of work per Sprint.

You need a release with all three functions in three months.

What do you do?


Work in teams* 5 minutes to discuss, analyse and propose a solution* 1 minute per team to present their solution* 5 minutes to reflect on the outcome.[15]

CollaborationScrum Teams


[20 start 11:00 end 11:20] [20 start 11:30 end 11:50]15 = 12:00 - 12:15

Basic truths about team motivation

People are most productive when they manage themselves

People take their commitment more seriously than other people’s commitment for them

People have many creative moments during down time

People always do the best they can

Under pressure to “work harder” developers automatically and increasingly reduce quality


“Technical debt” or “design death”

Basic truths about team performance

Teams and people do their best work when they aren’t interrupted

Teams improve most when they solve their own problems

Broad-band, fact-to-face communications is the most productive way for teams to work together


Basic truths about team composition

Teams are more productive than the same number of individuals

The optimum size team is around seven people, and no more than nine

Products are more robust when a team has all of the cross-functional skills focused on the work

Changes in team composition often lower productivity for a time


Any organisation that designs a system

(defined broadly) will produce a design

whose structure is a copy of the

organisation’s communication structure.

Melvyn Conway, Datamation, April 1968

Conway’s Law


Conway’s Law is receiving renewed attention.

listeningto the team


[listening to the team]* listening skills* team is responsible for quality - undone work - technical debt - mess

Group Dynamics Mover and Shapers


* Observers: 3 or 4 people standing on chairs or tables => offer insights after each exercise.1. Victim: Silently select one person to be your enemy and another to be your shield. Place your shield between you and your enemy.=> Group breaks up and moves outward => blame, avoidance2. Protector: Be the shield - silently pick an attacker and a victim. Place yourself between attacked and victim.=> Group will collapse on itself => covering up mistakes of others3. Egalitarian: Silently pick any two people. Try to form an equilateral triangle with them.=> Group will not come to rest; after a minute or two give instruction: “now resolve this!”[10-30]

simulation


day 2 | season 7 | 13:00 - 14:30

Scrum simulationResort Brochure


* Each table is a team...* Agree on a “wish list” for brochure for your ultimate holiday resort [5]* Write user stories: “As a parent, I want <…> so that <...>”; “As an owner…” [10]* Order user stories by importance (=business value) [5]* Plan 12-minute Sprint = 3 days x 4 mins including 1 min daily Scrum meeting [10] - for each story define acceptance criteria (=done) - commit to stories and create a Sprint goal - break stories into tasks (=high level design)* Run Sprint [3x4=12] - 1-min Daily Scrum to synchronise and select tasks - 3-min to work!* Review: each team gets 2 mins to demo & discuss progress [10]* Retro: each team discusses WWW and DD [10]

beyond basics


day 2 | season 8 | 15:00 - 16:00

scaling and distributed teamsLarger Scrum


* Remember Tobias’ comment on scaling: Scrum contains everything needed to scale - teams will simply self-organise into a viable structure (provided no-one prevents this from happening).

[40]

product owners product backlogs teams1 1 1

1 1 21 2 11 2 2

2 1 12 (n) 1 2 (n)

2 2 12 (n) 2 (n) 2 (n)

multi-team patterns

Huh?92Friday 09 April 2010

[scaling patterns based from Henrik’s presentation in Stockholm 2008]* queuing theory | pull | PO team | multi-product backlogs | multi-team planning, reviews, retrospectives[30]

money for

nothing changefor free


Why do we have contracts?A technique for fixed price / time / scope projects:* swap out any work (not yet started)* change priorities (not yet started)* additional releases at time-and-material rates* early termination for 20% of unbilled fee[20]

what puzzles you?

still


day2 | review of questions | 16:00 - 16:30

training course (& exam) practice—1 year guide level—3+ years

⎫⎬⎭

⎧⎨⎩


* Scrum Alliance certifications* Exam is currently only applicable to CSM course* Within the next two weeks you will be emailed a userid and password to the Scrum Alliance web site* You’re membership is paid for one year.* And remember that this certification only says you attended a 2-day course given by someone whom the Scrum Alliance trusts to teach Scrum.


day 2 | retrospective | 16:30 - 17:00* what am I going to do differently when I get back to work tomorrow?

ScrumSenseCopyright in these slides is owned by Peter Hundermark and Scrum Sense CC. Some content and images may the copyright of others. Every Certified ScrumMaster or Certified Scrum Product Owner trained by Peter Hundermark is permitted to use this slide set for non-commercial purposes.

[email protected]

www.scrumsense.com


certiﬁed - scrum sense · estimation meeting: formal capture and sizing of new backlog items....

Documents