Scrum Crash Course - Anatoli Iliev and Lyubomir Cholakov, Infragistics

Scrum Training

Infragistics Crash Course

Introductions

SCRUM what?!?

Raise your hand at the one that applies.

• Your level of experience with Scrum?

– Novice

– Somewhere in Between

– Expert

• How do you feel about Scrum?

– Skeptic / Doesn’t work

– In between

– Strong Advocate

Agenda

• 16:45 – 18:15 – Training

• 18:15 -19:45 – Lego game

Why scrum and agile…

Approaches Compared

Dealing with Uncertainty

What is “Scrum”?

The Three Pillars of Scrum

Scrum Roles

Agile Teaming

Whole Team

Scrum Roles

Others Team Members

Roles of the Team

Agile Requirements and specs

Modeling Summary

Iteratively and continuously, understand users, refine requests into lightweight requirements that meet there's needs and our product / project then create just enough specs so that we can build

Context (product vision, business case)

Stakeholders

Product ownerRequirements

Scrum Team

Requirement – More than Just a Story

• Matured request that identifies attributes, capabilities and qualities that a system must possess for it to provide value

• A key component a user story or other concise expressions of a request

• Provides perspective to envision enough of the implementation possibilities to assign a story point estimate and re-prioritize

Requirement, more than a just a user story, enough to plan

User Stories

User story template is simplistic, it helps us remember a need while providing content

As a driverI want to find a conveniently located branch So that I can minimize travel time

User, User role, Persona (WHO?)

Specifies the primary beneficiary, others ca also use.

Desired Function (WHAT?)

End Result (WHY?)What is not specified and why?

User Stories - Samples

First attempt with context

As a user

I want to modify system users

We want administrators to be able to assign access privileges to users based on their role to secure access to functions and data based on need to know / do.

Improved, Good Enough?

Specification, Ready to Build

To be confident we can complete our sprint work just enough specs, just in time, to allow us predictably build

• Often we need nothing more than the requirement and a quick conversation

• We may also benefit essential use cases, prototypes, API signatures ,sample XML, etc. to clarify external or internal design

Spec RequirementsAdditional

ConversationsExamples /

Designs

Context (Project Vision, Design Standards, etc.)

Ceremonies and Artifacts of Scrum

Discovery

Discovery Sessions at a Glance

Description

Series of facilitated sessions to orient team to the project’s business value, the process, and one another, while preparing to excellence. Not part of Scrum Framework but often helpful.

Duration

One day – multiple weeks

Attendees

Team, Product Owner, Key Stakeholders, Scrum Master, Subject matter experts

Outputs:

• Product Vision• Project approach• Team norms• Team rooms• Business process

definition

• Initial backlog• Dev. + test

environments• Dependency list• Risk list• Etc.

Discovery, aka Iteration 0

• Agile Process Training

• Product Discovery

• Product Roadmap

• Initial system design

• Architecture spike

• Collaborative modeling workshop

• Feature and epic prioritization and estimation

• Team Discovery

• Team norms and core hours

• Sprint duration

• “Ready” and “Done” definition

• Team structure (core / extended)

• Stakeholder / Project interactions

• Process Discovery

• Process value stream map

• Supplier customer diagram

• Key metrics (CTQs)

• Project Discovery

• Sponsor vision and business context

• Preliminary release planning

• Preliminary sprint planning

• Major dependencies and risks

• Environment

• Version control and build environments

• Team room

• Team board

Sample Discovery Session(s) might include:

Release Planning

Release Planning at a Glance

Description

Optional, but recommended project planning session, to review initial Product Backlog and set production Release dates.

Duration

Depends on team maturity, ideally under one day.

Attendees

Team, Product Owner, Scrum Master, Subject matter experts

Outputs:• Referred product backlog with initial /

updated estimates and priorities• Updated release plan• Updated roadmap

Scope vs. Backlog Size

Product Backlog

Agile Estimating and Forecasting

Two Levels of Estimating

Release planning estimates are

done with RELATIVE STORY

POINTS focusing on Size,

Complexity and Risk

3 is 50% bigger than 2

A modified Fibonacci sequence

1, 2, 3, 5, 8, 13, 20, 20 &

100

T-shirt sizes – XS, S, M, L, XL

Over time, story points

automatically encompass

external interruptions, technical

surprises, developer skill level,

unplanned absences, domain

knowledge and other factors

Doesn’t decay over time

Sprint Level estimating sometimes

includes a look at story points, and

sometimes task level estimating

Task hours

Task sub points

Estimate with Story Points - benefits

Relative measure of Size, Complexity and Risk

3 is 50% bigger than 2

A modified Fibonacci sequence

1, 2, 3, 5, 8, 13, 20, 20 & 100

T-shirt sizes – XS, S, M, L, XL

Over time, story points automatically encompass

external interruptions, technical surprises, developer

skill level, unplanned absences, domain knowledge

and other factors

Doesn’t decay over time

Based on “Wideband Delphi” convergent estimation

techniques

1. Each team member (estimator) has a deck of cards

2. Moderator (PO) reads a story and it is briefly

discussed

3. Estimators select a card & places it face down

on the table

1. Cards are turned over all at once

2. Outliers are discussed

3. Re-estimate is run until estimates converge

(or don’t!)

Estimation Try 1 Try 2 Try 3

Konstantin 3 5 5

Ivo 8 5 5

George 2 3 5

Monika 8 5 5

Planning Poker in Action

Planning Poker Approach 0. Define the meaning of 1

1. Each estimator has a card deck (whole team)

2. A Moderator (PO) reads a story and it is briefly

discussed

3. Each estimator selects a card and places it face

down on the table

4. Cards are turned over all at once

5. Differences (especially outliers) are discussed

6. Re-estimate until estimates converge (or don’t)

Velocity Basics

Sum of planned, completed functionality in

a Sprint, for example:

Team estimated 36 points worth of

stories during Sprint Planning

One story, worth 8 points was not

completed, the others were

Their current velocity is _____

points?

Work actually completed in prior sprints, all

things being equal, is a good predictor of

work that can be completed in the future

Effective is a release planning metric

Not effective as a productivity metric or

to compare across teams

Measure work completed, forecast future throughput

Product Backlog at a Glance

Discovery Session

Release Planning

Product Backlog

Production Ready

Features

BurndownSprint

Backlog

Sprint Planning

Daily Scrum

Work

Sprint Review

Sprint Retro

Start Sprint Daly Scrum End Sprint

Description

List of desired functionality for a project prioritized by business value by the PO

Managed by

• Contains requirements as “User Stories”

• Top priority stories are better defined

• DEEP• Detailed Appropriately• Estimated• Emergent • Prioritized

Key Characteristics

• PO / Scrum Master

Contains:• Prioritized Product Backlog Items or User Stories• Rough Estimates• Forecasted iteration boundaries• Release Dates

Sample Product Backlog

ID Backlog Item Acceptance Criteria Points Sprint

1 114 As a GuestI want to Make a ReservationSo that I can get a room of my choice

Confirmation e-mail is sent Must be made > 24 hours in

advance

2 S1

2 127 As a GuestI want to Cancel a ReservationSo that I can receive a full refund

Confirmation e-mail is sent Must be cancelled > 24

hours in advance

2 S1

3 109 As a GuestI want to change reservation dates

….. 4 S1

4 112 As a hotel employeeI want to see future reservations

…… 8 S2

… …. ….. …… …

41 416 …………. …… S99

Sprint

Sprint at a Glance

Discovery Session

Release Planning

Product Backlog

Production Ready

Features

BurndownSprint

Backlog

Sprint Planning

Daily Scrum

Work

Sprint Review

Sprint Retro


Description

Time boxed iteration that consists Of Sprint Planning, day to day Work , Daily Scrum, Sprint Reviewand Sprint Retrospective

Involves

• Isolated from further changesThat would affect Sprint Goal

• Work organized adaptively

• 1- 4 Weeks

Key Characteristics

Duration

• Team, Scrum Master, PO, SMEs

Outputs:• Daily updates of Burndown charts or CFD• Potential shippable functionality • Other necessary items, as prioritized by Product

Owner

Sprint Backlog

Sprint Backlog at a Glance

Discovery Session

Release Planning

Product Backlog

Production Ready

Features

BurndownSprint

Backlog

Sprint Planning

Daily Scrum

Work

Sprint Review

Sprint Retro


Description

List of desired functionality and tasks for the team to get productBacklog items to done in the current sprint

Managed By

• Created at Sprint Planning• Updated throughout Sprint as

tasks are added / removed

Key Characteristics

• Team, Scrum Master Outputs:• Prioritized User Stories & their constituent tasks• Task-level estimates (optional ) in hours• Other information necessary to understand the

work at hand

Sprint Planning

Sprint Planning at a Glance

Description

Meeting to elaborate, estimateand prioritize highest-value UserStories, creating Sprint Backlog

Duration

Attendees



Discovery Session

Release Planning

Product Backlog

Outputs:

• Estimate and Prioritized User Stories• Updated Acceptance Criteria• Sprint backlog Tasks ready

Production Ready

Features

BurndownSprint

Backlog

Sprint Planning

Daily Scrum

Work

Sprint Review

Sprint Retro


Sprint Planning Preparation

Description

• Product Owners should arrive prepared to discuss top priority stories and ask any questions regarding alternative development paths

• The Scrum Master should arrived prepared with capacity planning and logistical information, such as who is in, whose is out, who is working from home, expected velocity, etc.

• Team members should have reviewed stories and determined initial estimates and questions about development scenarios

• Acceptance criteria should be clear and well articulated

• Depending on the needs of the team, other supporting material, like wireframes, should be created

From User Stories to Tasks

Daily Scrum

Daily Scrum at a Glance

DescriptionDaily meeting to inspect progress against Spring goal, to make adaptations that optimize the value of the next days work.Focused on making trade-offs, coordinating efforts and risk management.

Duration10-15 minutes

AttendeesTeam, Scrum Master, optionally Product Owner and interested Stakeholders.

Outputs:• Updated Schedules• Task Board Updated• Risks and Issues Identified• Informal follow up meetings (Sit-Downs)

arranged

Initialmeeting

Discovery session

Release

planning

Product backlog

Sprint planning

Daily scrum

Work

Sprint Review

Sprint Retro

Ready features

Start of Sprint Daily End of Sprint

Sprint

Sprint backlog Burndown

Daily Scrum Format

Sprint Boards and Tracking

Sprint – Task Board with WIP Limits

Team Board

Sprint Burndown: Summary

DescriptionSimple tool for Team to track progress during a Sprint

Key Characteristics• Shows work remaining, not

work completed• Traditionally have burned

down task hours, many now burn down story points

Ideal line shows the necessary angle for completion

Managed byTeam, ScrumMaster,

Represents Progress versus Plan:• Below the line good• Above bad• Trend is also important

Sprint Review

Sprint Review at a Glance

Outputs:• New features on Product Backlog• Reprioritized Product Backlog• Revised Team or Project Structure

Initialmeeting

Discovery session

Release

planning

Product backlog

Sprint planning

Daily scrum

Work

Sprint Review

Sprint Retro


Sprint


DescriptionPO identifies what has been done versus plan, team demonstrates completed functionality, and attendees collaborate on what to do next.

Duration4 hours for 1 month Sprint,2 hours for 2 week Sprint, etc.

AttendeesTeam, ScrumMaster, optionally Product Owner, optionally Users and Interested Stakeholders.

Ready features

Sprint Review

Sprint Retrospective

Sprint Retrospective at a Glance

Outputs:• New features on Product Backlog• Reprioritized Product Backlog• Revised Team or Project Structure

Initialmeeting

Discovery session

Release

planning

Product backlog

Sprint planning

Daily scrum

Work

Sprint Review

Sprint Retro


Sprint


DescriptionSM guides team to inspect how last Sprint went (people, relationship, process and tools) to identify “pluses” and deltas to create a plan for change with the framework for upcoming Sprints.

Duration3 hours for 1 month Sprint,1.5 hours for 2 week Sprint, etc.

AttendeesTeam, ScrumMaster, optionally Product Owner.

Ready features

Sprint Retrospective Essentials

Ready and Done

Definition of Ready

“Don't let anything that's not READY into your Sprint, and let nothing escape that's not DONE.”

(Serge Beaumont about definition of ready)

“ Backlog must be READY before taking into SprintSoftware must be DONE at the end of the Sprint”(Jeff Sutherland in presentation)

Serge Beaumont: ‘READY is when the team says: "Ah, we get it“’.✓Why? Business value✓What? Outcome vision✓ How? Implementation strategy & cost✓ User story have been estimated, backlog is prepared for 1,5 -2 sprints.✓ Is the Granularity OK?

http://blog.xebia.com/2009/06/19/the-definition-of-ready/

http://www.scrumalliance.org/resources/1116

Sample Definition of “Done”

Closing

Scrum Crash Course - Anatoli Iliev and Lyubomir Cholakov, Infragistics

Technology

Transcript of Scrum Crash Course - Anatoli Iliev and Lyubomir Cholakov, Infragistics