P. 1
Day1 CoreScrum Training

Day1 CoreScrum Training

|Views: 101|Likes:

More info:

Published by: 황순삼(Sam Hwang) on Jan 11, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/11/2011

pdf

text

original

Core Scrum

Sam Hwang Sep 2009

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

Outline 1 of 2

• Overview • Scrum Team Roles • Product Backlog • Sprint Planning Meeting • Sprint Tracking
• • •
Defined vs Adaptive Process Origins of Agile Scrum Process Diagram

Outline 2 of 2
• •
Sprint Planning Meeting Simulation Sprint Rules!

• • • •

• • • •

Potentially Shippable Done (Again) Changes / Termination Sprint Length

Stand-up Dysfunctional Standup Exercise Sprint Review Sprint Retrospective

A defined process
A defined process

• Every task must be completely understood.When given a well-defined set of inputs, the same outputs are generated every time.

Is software development a defined process?
• Is every task completely understood? • Given the exact same inputs (including people)
Will we get the same results every time? Can we even have the exact same inputs?

Adaptive process control
• Useful when
Process cannot be sufficiently described to ensure repeatability

• Embrace Change • Inspect and Adapt

An Iterative Process
Design Test
Bui ld

v2.0

v2.1

Innovate

v2.3

v2.4

What is Agile?

Origins

• Scrum • Extreme Programming • Others

• • •
“The New New Product Development Game,” HBR, 1986. Schwaber, Beedle, Sutherland on Scrum starting in 1995.

Kent Beck, Ward Cunningham, Ron Jeffries, 1999

Lean

Feature-Driven Development

The Agile Manifesto

• February 2001
statements

• 17 advocates of “lightweight methodologies”

• Result was a manifesto of four value

got together to see what they had in common

The Agile Manifesto
Individuals and Individuals and interactions interactions Working software Working software Customer Customer collaboration collaboration Responding to change Responding to change
over

Process and tools Process and tools Comprehensive Comprehensive documentation documentation Contract negotiation Contract negotiation Following a plan Following a plan

over

over

over

Agile
Adapt Embrace change. Give up on “managing” and “controlling” it Get Feedback Show work early and often, make it visible and get constant customer involvement Deliver Value Work on highest value and riskiest features first. Release frequently. Reduce waste. Collaborate Whole team thinking, owning and solving problems with the customer. Communicate Big visible charts, information radiators, daily meetings. Regular planning sessions. …Continuously Short timeboxed iterations.

This is NOT Agile

• Compress the schedule • No documentation • Hack code • No design or planning
The organization may gain short term speed at the cost of long term gain.

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

The Scrum Process

The Scrum Team

Scrum Master Product Owner

The Stakeholders

Product Owner
• • •
Product visionary Maximizes business value Prioritizes and clarifies requirements

• Plan • Prioritize • Collaborate

Deliver Value

Product Owner
• Defines the features of the product, decides on release date and content • Is responsible for the profitability of the product (ROI) • Prioritizes features according to market value • Can change features and priority in the product backlog • Accepts or rejects work results • Communicates with the business

Scrum Master

• Serves the team • Tracks progress • Guards the Scrum process

Scrum Master
• Ensures that the team is fully functional and productive • Enables close cooperation across all roles and functions and removes barriers • Shields the team from external interferences • Ensures that the process is followed. Participates in daily scrum, sprint review and planning meetings

The Team

Meet Daily

Work

Sprint Tasks

Produce product increment

The Team

• Cross-functional • Self-Organizing

Stakeholders

• Prioritize • Collaborate • Serve

Review

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

Product backlog
A prioritized list of requirements

• Items of highest value at • Prioritized by the
This is the This is the product backlog product backlog

the top

• Estimated by the team

product owner

A sample product backlog
Backlog item
Allow a guest to make a reservation As a guest, I want to cancel a reservation. As a guest, I want to change the dates of a reservation. As a hotel employee, I can run RevPAR reports (revenue-per-available-room) Improve exception handling Bug #4334 – Improve error handling with… Investigate PayPal integration

Estimate
3 5 3 8 8 1 9

Common product backlog estimating units

Ideal Time Calendar Time

Ideal Time -or- Calendar Time
Ideal time • The amount of time something is likely to take one person if they aren’t disrupted or distracted • If two people will work on it, their time is added • Often expressed in days (including ½ day, etc.) Calendar Time • Just old-fashioned guessing at the hours or days something will take

Estimating the Product Backlog

• Use coarse-grained estimates for the • Think: “Days” or “Weeks”
Product Backlog

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

The Scrum Process

Sprint Planning Meeting

Sprint Review/ Sprint Retrospective

Sprint Planning

Team takes a subset of the product backlog and commits to delivering it for the sprint.

Sprint Planning
Objective
In Sprint Planning, the Team determines a list of features to be developed in the current sprint.

Victory Conditions
They’ve defined a clear goals for the sprint They’ve come up with a task-driven plan for achieving it They can make a commitment to completing that plan

Sprint Planning Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Equipment
1.5 to 2 sprint's worth of Product Backlog Post-it notes / Whiteboard

Sprint Planning Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Players
Team Members Product Owner

Sprint Planning Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Rules

Determine the team’s initial capacity

• • •

Get velocity using yesterday’s weather Multiply by the number of days in the sprint Adjust for known contingencies

Sprint Planning Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Name Anne Rita Michael Eduardo Base Hours 3 hours 3 hours 3 hours 3 hours Less Vacations, Holidays, Etc 1 day 1 day 3 day 1 day Total 27 hours 27 hours 21 hours 27 hours

Based on Yesterday’s Weather

Sprint Planning Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Rules
• Select an item from the product backlog and discuss • Break down into tasks to complete the item • Estimate amount of work for each task • If team has capacity left, proceed with next item; otherwise, stop – sprint planning is done
Sprint Planning Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Rules

• Players volunteer for task • Volunteer estimates task
• • •
Estimate is subtracted from their bandwidth Don’t know enough to estimate? Spike Estimates are in hours, typically 2-4 hour tasks

Sprint Planning Description Equipment Players Rules: 1 Rules: 2

Sprint Tasks: Yahoo! Example

Sprint Planning: Done
Definition of “DONE” helps clarify goal

• Mockups, schemas to review • Usability results • Fully tested and staged code

Sprint Planning Values and Insights
• • • • • • • • •
Volunteering “Done” Yesterday’s Weather

• •

Improved predictability Humane work

Team Commitment => taking a stance Who is involved / who is the team Declaring personal availability before accepting work so that you don’t feel like a badguy when you turn down work Self-empowerment Team alignment Time boxing

• •

Fixed : resource and time Estimate: Requirement/Value

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

1,000 800 600 400 200 0 4/29 5/13

Tracking Progress

Tracking Progress
Description
In Task Tracking, the Builders provide incremental information about their progress, which is then converted into a global picture of how well the team is progressing.

Victory Conditions:
They know whether or not they can fulfill their sprint commitments

A sprint burndown chart

Hours

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

Sprints

Sprints
During the sprint:

• • • •
This is the This is the sprint sprint

Analysis Design Code Test

Always deliver
• Always deliver a potentially shippable product increment at the end of each sprint • Do not miss the end of the sprint
The deadline is sacred

Potentially shippable product increment
• High quality • Tested • “Done” Potentially shippable ≠ shippable

The scope of “done”
Planning Planning Analysis Analysis Design Design Coding Coding Testing Testing Performance Performance User Acceptance User Acceptance Pilot Pilot Live Live

!

Extend the scope of “Done” as far as possible

Defining “Done”
Pair with someone you don’t know. Turn to each other and share short answers to the following for 5 minutes:

1 2

What does “Done” mean in your current project? “Done” What issues do you see with this definition of done? How would you address them?

3 What engineering problems do you see with this
approach? How would you rectify them?

Sequential vs. overlapping development

Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time

Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

Queuing theory
Cycle Time as a Function of Utilization and Batch Size*
45 40

Cycle Time (hours)

35 30 25 20 15 10 5 0 10% 20%

Large Batches Medium Batches Small Batches

30%

40%

50%

60%

70%

80%

90%

100%

Queuing Theory 101
*This assumes batch size is proportional to variability.

Little’s Law

• The long-term average number of customers in
a stable system N, is equal to the long-term average arrival rate, λ, multiplied by the longterm average time a customer spends in the system, T N=λT

• In other words:
Total Cycle Time =

Number of Things in Process Average Completion Rate

Exercise 1
• • • • • • •
• •
Make teams of 5 people
4 will operate 1 will measure (using chronometer)

Put 20 cards face up in front of you Start the chronometer Move all cards to your neighbor and flip down all of the 20 cards (one by one) When the 20 cards are moved, your neighbor move all cards to his neighbor and flip up all the cards Do it again … till the last member of the team Stop the chronometer

Exercise 2
• • • • • • •
• •
Make teams of 5 people
4 will operate 1 will measure (using chronometer)

Put 20 cards face up in front of you Start the chronometer Move 1 card to your neighbor and flip down this card When 1 card is available for your neighbor, he takes it and moves it to its neighbor and flip up this card Do it again … till the last member of the team and the last card Stop the chronometer

Discussion

• Compare the 2 results (duration) • What is the fastest organization • Could you explain why?
• Don’t forget to use mathematics ☺
Large Batch generates long period of waiting Average completion rate is similar (time to flip 4 times a card) but the number of things in process is reduced

Deliver Fast

• Now, you know how to deliver fast
• Reduce Number of things in the Process
• •
Use SCRUM approach (short iterations)

• Reduce size of requirements
Use MMF approach (see next section)

Reciprocal commitments

The business commits to leave priorities alone during the sprint

No changes during a sprint
• What the team commits to—and what the product owner agrees to—during sprint planning should be what is delivered
However, keep in mind that... • We start with vague requirements. Our understanding of those requirements is refined during the sprint.

Abnormal Terminations
• If change cannot be kept out of a sprint...
The sprint may be abnormally terminated

• An extreme circumstance, not done very often • Raises visibility of priority changes

Average time to implementation
A change that is identified here… …gets planned into this sprint…

Week 1 Sprint 1

Week 2

Week 3 Sprint 2

Week 4

…and delivered here.

The Lesson
Reproduced with kind permission by Mike Cohn mountaingoatsoftware.com

Average change is delivered 1½ sprints after being discovered.

Sprint length • Most common lengths:
• 2-weeks, 4-weeks
Factors to consider…

•How long the business can go without changing its mind •Pick a length that spreads intensity appropriately •Ability to reliably predict effort on tasks four weeks out •Length of the overall release •Amount of uncertainty on the project •The overhead of iterating

Sprint Length

• Keep the same sprint length for all your sprints.

• Be sure to run sprints back to back. • Always end the sprint on time
These Policies
• Promote regularity • Establish a heartbeat

Don’t change length arbitrarily from one sprint to another

Intensity varies over time
Waterfall

Intensity

Scrum

Months

Sprints
1 2 3
Is there such a thing as an “analysis sprint” where “analysis sprint” requirements are pulled together? Is there such a thing as a “testing sprint”? “testing sprint”? If a project requires a lot of infrastructure and architecture work that will take eight weeks to complete, should the first sprint be eight weeks long? Is the architecture an adequate deliverable?

Release Sprints
• Always target a potentially-shippable product increment • But, some polishing can occur in a release sprint
Some stress, performance or usability testing Compliance Documentation touchups (final screen shots)

A Sprint Warning

Don’t let work slop over from sprint to sprint and build up

100

150

200

250

300

350

50

Monday Tuesday Wednesday Thursday Friday Monday Tuesday Wednesday Thursday Friday

Will this sprint finish on time?

0

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

Stand-Up

Stand-Up
The stand-up is..

• A 15 minute meeting • A forum for team members to
answer

• • •

What I did What I plan to do today What is blocking me

Why Stand-ups?
• Understand what is in play • Increase Collaboration

Good Stand-ups:
• Allows for efficient collaboration • Demonstrate respect

Sprint Review

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

Sprint Review
Description
In the Sprint Review, the team demos the completed features (and other products of the sprint) to all interested parties.

Victory Conditions

• • •

Everyone understands where the product is and what it can do at this point in time Valuable feedback is acquired from Stakeholders Everyone has fun

Sprint Review
Equipment

• • •

A functional product that was finished at the end of the sprint Demonstrable on a staging server Other work artifacts to demonstrate

Sprint Review
Players

• The Whole Team • Any Stakeholder who is interested
• •
Developers, Testers, UED, etc Product Owner

Sprint Review
Rules

• Hold a 30 minute informal presentation • Limit the prep time to 2 hours total • Be careful not to do additional work just
for the review!

Course agenda
Today
• Overview of Agile and Scrum • Roles on a Scrum Team • Product Backlog • Sprint Planning • Sprint Tracking • Rules of Scrum • Stand-up • Sprint Review • Sprint Retrospective

Sprint Retrospective

Sprint Retrospective
Description
In the Sprint Retrospective, the Team takes stock of what did and didn’t work during the last sprint, and comes up with strategies to improve their processes and development methods.

Victory Conditions
Inspect & Adapt

Sprint Retrospective
Players

• •

Team Members

• •

Builders Product Owner

No Other Stakeholders!

Sprint Retrospective
Rules

• •

Typically 30-60 minutes Done after every sprint

Sprint Retrospective

• Whole team gathers to discuss:
Progress What’s working What’s Improvements

Sprint Retrospective
Start

• • • • • • • •

Stop

Showing the software to customers early Specifying acceptance tests early and with customers Doing code inspections Getting FitNesse into the nightly builds Trying to finish one story before moving to the next Being disrespectful of QA Making progress with the canonical database Emphasizing test automation

Continue

Thank You!

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->