Getting into SCRUM

Presented by Sue Bramhall (accredited by the Scrum Alliance) for DVT

Material acknowledgements: Peter Hundermark, Boris Gloger, Ken Swaeber, Mountain Goat Software, Henrik Kniberg (Crisp), 3back
Property of Sue Bramhall Oct 2008

Some of the benefits of Scrum

Every 2 weeks to a month, anyone can see real working software and decide to release it as is or continue to enhance it for another sprint. Deliver the highest business value in the shortest possible time

Inspect actual working software regularly

Business sets the priorities Teams self organise to deliver the highest priority features Some companies using Scrum (already outdated): Microsoft, Yahoo,Google, Phillips, Siemens, Nokia, BBC, Nielsens Media, John Deere, Time Warner, 24.com, Allen Gray, Korbitec, Direct Axis

Property of Sue Bramhall Oct 2008

The Scrum Flow

Entire Project

Selected Stories

Tasks

Property of Sue Bramhall Oct 2008

Product Backlog
Product Backlog
A prioritised list of items ( features) based on the vision of the Product Owner Items a reminder to converse Items should be measurable against acceptance criteria Living artifact, continually changing and being reprioritised Higher priority items clearer than lower priority items Items needs to be estimated by the people doing the work

Property of Sue Bramhall Oct 2008

The Product Owner creates and maintains the Product Backlog! Never show up to a Sprint Planning session without an estimated and prioritized Product Backlog. Make it public to the organization!

Property of Sue Bramhall Oct 2008

Sprint planning 1
Sprint 0
Team is gathered to estimate entire backlog this happens at the beginning of each new project Team and PO negotiate the priority of items on the list.

Sprint 1
Product owner presents what he would like in the sprint, with a Goal and user stories. Team questions, negotiates and selects stories they can commit to during the sprint. Team re-estimates stories if required The committed items are called the Sprint Backlog Time-Box: 2 hours for a two week sprint
Property of Sue Bramhall Oct 2008

Sprint planning 2
SP2 is for the team to figure out what tasks will be required for each story breaking down the work. The team drives the session the PO needs to be available for any questions. Time box: 2 hours for a two week sprint

Property of Sue Bramhall Oct 2008

Sprint starts
The sprint starts
The daily scrum or stand up Team members report back using 3 things:
What I did yesterday What I will do today List any impediments

The team members synchronize their work during this daily inspect and adapt cycle. Any impediments are raised by the Scrum Master Team left alone for the duration of the sprint The sprint results in Potentially shippable product.
. View scrum board on next page
Property of Sue Bramhall Oct 2008

Property of Sue Bramhall Oct 2008

Sprint Review
Looks at what the team is building The team presents what they have completed or that are Done for the sprint to PO and stakeholders Was the sprint goal achieved? The team should have completed all backlog items but achieving the goal is more important.

Property of Sue Bramhall Oct 2008

Sprint Retrospective
Looks at how things are being done Provides the team with an opportunity to inspect and improve Anything that affects how the team builds software can be discussed: processes, practices, communication, artifacts, tools, etc.

Property of Sue Bramhall Oct 2008

Burn downs
Sprint burn down
Is an indicator of the teams progress through the sprint Is updated daily Burn down is effort vs time

Product Release burn down

Is an indicator of the teams progress through the Product backlog. Sprints vs time
end
Property of Sue Bramhall Oct 2008

Estimation and Planning

Estimate using Story Points estimate the size and complexity of work not days and hours 1 magnitude Story points represent nebulous units of time Iteration short, constrained period of time Release Multiple iterations Units of work user stories Velocity Amount of work completed in a sprint The estimators do the work Estimating drives discussion and understanding Estimating avoids meaningless arguments See Planningpoker.com Mountain Goat Software
Property of Sue Bramhall Oct 2008

Definition of Done
The team decides that an item is DONE when: Coded and implemented to meet the acceptance criteria Peer reviewed (pair programming counts as peer review) Code is run against current version in CVS Code is checked in Test plan has been updated SDs updated QA passed UAT passed Code is live Unit tests written and passing (for the object/class) All to-do items in code are completed

Property of Sue Bramhall Oct 2008

In conclusion......

Property of Sue Bramhall Oct 2008

Property of Sue Bramhall Oct 2008

Thank you!
Property of Sue Bramhall Oct 2008