Scrum OverviewRob Bastian

The definition of insanity is doing the same thing over

and over and expecting different results. Benjamin Franklin

Scrum Key Takeaways

• Self directed, self organizing cross functional team

• Planning driven by customer prioritization

• Time boxed iterations

• Daily stand up meeting

• Demo at end of each iteration

What is Scrum anyway?

• Scrum is a process for developing products such as software and quickly getting the products to the customer.

• Iterative and incremental development method• Emphasis on empirical process management

rather than defined process– Empirical means “Originating in or based on

observations and modifications”

• CMM Level/3 and ISO 9001 compliant

Royce: The Waterfall Model

• In 1970, Dr. Winston Royce published “Managing the development of large Software Systems”

SystemReq. Software

Req.Analysis Program

Design CodingTesting

“I believe in this concept, butThe implementation described above isRisky and invites failure”

Royce: The Waterfall Model

• On the next page showed the following:

SystemReq. Software

Req.Analysis Program

Design CodingTesting

“Hopefully, the iterative interaction betweenThe various phases is confined toSuccessive steps

Waterfall is a powerful attractor

• For Management– It is a “defined process” – thus “feels right”– It gives the illusion of control

• Of time• Of people• Of money

– Allows for “hands off” management

• For Developers– It’s just “following a recipe”– Left alone for long periods of time

Why is Waterfall less than optimal?

• Built on the assumption that we can figure out what we need to do ahead of time and then plan accordingly

• Building software is about solving problems and not all problems can be anticipated so the ability to constantly change course in the face of issues is critical

“No no no, I'm going to leave them alone and not actually witness them dying, I'm just gonna assume it all went to plan. What? “ – Dr. Evil

Why is Waterfall less than optimal?

• One study showed that typical requirements specifications are 15% complete and only 7% correct and that it was not cost effective to complete or correct them

• Evidence/data indicates that more detailed up-front requirements not only does NOT help much in preventing requirements change, but in fact makes requirements change MORE likely (because many of the details you tried to "guess" up-front we're wrong and have to be changed)

Why is Waterfall less than optimal?

• We can’t really know what we need until we see a little of what we have– Customers change their minds– Developers see new possibilities– New function often require new designs

• Building an architecture up front assumes:– You know what you really need– You don’t overbuild it– People will follow it– It anticipates all needs and doesn’t need to change –

that is architectures are often built to be filled out, not to evolve as needs change

Why is Waterfall less than optimal?

• Features aren’t prioritized– Why prioritize features if they’ll all be implemented?– Developers potentially work on least important

features first– Most important features may not get done

• Testing always gets impacted– The reality is the delivery dates are hard to move– Engineering tasks that take longer than anticipated

will “steal” time from the QA team – “Stealing” from QA costs more later…

How is Scrum different?

• Planning and Prioritization

• Iterations, Increments and Features

• Refactoring and Emergence

• Self-organized and Cross Functional Collaboration

How is Scrum different? Planning and Prioritization.

• Planning– Scrum team meets with stakeholders at the

beginning of an iteration to plan what work will be taken on during the iteration

– Scrum team meets every day for 15 minutes to plan daily work

• Prioritization– Stakeholders prioritize features so we know

we’re working on most important features first

How is Scrum different? Iterations, Increments and Features

• Feature driven– Scrum teams focus on building vertical slices of an

application feature by feature– Three/four levels of “done”

• Time boxed– Team works in iterations– Team decides how much work will “fit” into the

iteration– At the end of an iteration a increment of working

functionality is delivered– At the end of an iteration the team demonstrates what

it built to stakeholders

How is Scrum different? Refactoring and Emergence.

• No big up front design– Architecture/infrastructure emerges as

features are completed and refactoring is done

– Refactoring MUST be done as features are implemented or you’ll be toast

• You Aren’t Going to Need It (YAGNI)– It’s better to let the features drive the

architecture as they are developed than to attempt to build it all up front

How is Scrum different – Self organized and cross functional collaboration

• Self Organization– Team should decide how best to accomplish the goal

of the iteration

• Team Swarm– Entire team can “swarm” on an issue or task until it’s

complete – e.g. writing acceptance tests

• Cross Functional– Anyone should be able to contribute to any task

(within reason)

Scrum Process

• Sprint Planning Meeting

• Sprint

• Daily 15 minute meeting (Scrum meeting)

• Sprint Review

• Retrospective

Sprint Planning Meeting

• Part I – Establish a Sprint Goal– Product owner prioritizes work for team for the next Sprint

(iteration) and works with team to determine how much work will “fit” into next Sprint

– Work is defined in the Product Backlog document that contains all known and outstanding enhancements and non-critical bugs

– Product owner is ensured that only highest priority work is being done

• Part II – Task Breakdown and Estimation– Team breaks down product backlog items into work or tasks no

more than 16 hours in length– Tasks include QA tasks, unit and rtests, platform processes like

design documentations and code reviews– If tasks cannot be identified because not enough investigation is

done then investigation tasks are tracked to determine approach

Example Product BacklogNew Message Boards Product/Feature/Bug Backlog

Priority Description Type Date

Added

Initial Estimate (hours)

Planned Estimate (hours)

Target

Very High

72060 - NBA Live 06 Skinning E 9/6/05 32 24 6.4.0#2

Very High

Battlefield automated forum creation for clans E 9/30/05 60 6.4.1

Very High

Install “Powered by Jive” logo on site E 8/31/05 4

Very High

71997 – Preference center doesn’t work for EA.com accounts B 9/14/05 4

6.4.1

High 72062 - Battle for Middle Earth II skins E 9/14/05 40 High 72662 - User Defined Polls E 8/31/05 40

High Sticky Posts E 8/31/05 40 High Use anti-aliased icons for black background categories E 8/31/05 24 High Custom signature files E 8/31/05 40

Medium Custom Avatars E 8/31/05 60

Medium 72682 – Hidden threads should be marked using the “Hide” thread icon

E 9/26/05 16

Low 72025 – Preview page doesn’t show avatar, correct TZ or message signature

B 9/16/05 4

Low 72529 – Delete all messages from admin pages doesn’t work B 9/23/05 4 Low 72527 - Upgrade Jive software to 4.2.x E 9/21/05 80 Low 72526 - VIPs should auto redirect to categories E 9/23/05 36 Low 71997 – Preference center doesn’t work for EA.com accounts B 9/14/05 4

Low 72024 – Message signature from EA Nation preferences isn’t working

B 9/16/05 16

Low Users should have the ability to jump to the last page in a thread E 9/16/05 8

Sprint

• Fixed length iteration. Recommendation is 30 calendar days

• Team and Customer agree on what work can be completed during Sprint and define a goal

• Team self organizes to do work• Team conforms to standards and procedures• Team only works on tasks directly related to

completing sprint goals

The Daily Scrum Meeting

• Attended by developers, testers, analysts, customers and Scrum master

• Normally standing meeting to encourage brevity. 15-20 minutes

• No other discussion beyond the 3 questions– What did you do since we last met?– What are you going to work on next?– Is there anything impeding your progress?

• Scrum master tracks and resolves issues• What does “done” mean

Example Sprint Backlog and Burn Down Chart

Release 6.4.1 10/25

Sprint Start Date: 9/27

Sprint End Date: 10/17

Velocity 108

Working Days Left: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Remaining Effort in Hours

Item #60 42 38 23 23

72060 - NBA Live 06 Category & Forum Skins 24 8 4 1 171996 - Preference center should pop-up for XBL and PS2 accounts 8 8 8 4 4

71997 - Preference Center doesn't work for EA.com accounts - Investigation 2 0 0 0 071997 - Preference Center doesn't work for EA.com accounts 4 4 4 0 0

72060 - QA Verify 6 6 6 6 672062 - QA Verify 6 6 6 6 671997 - QA Verify 4 4 4 0 072662 - QA Verify 6 6 6 6 6

Sprint Burndown Chart

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Date

Re

ma

inin

g E

ffo

rt i

n H

ou

rs

Sprint Review Meeting

• Empirical observation by management and stakeholders on progress of the project

• The scrum teams shows accomplishments during the sprint– Demo– Informal

• All stake holders are invited• Project assessed against sprint goals• Maintains trust by not hiding undone work• Functionality

A Metric Leading to Agility

• Running Tested Features– The desired software is broken down into named

features (requirements, stories) which are part of what it means to deliver the desired system.

– For each named feature, there are one or more automated acceptance tests which, when they work, will show that the feature in question is implemented.

– The RTF metric shows, at every moment in the project, how many features are passing all their acceptance tests.

A Metric Leading to Agility (cont)

Retrospective

• Scrum team and customer attends

• Process improvement at the end of every sprint

• What went well, what can be improved

• What does management need from us

• Team devices solution to most vexing problems

Appendix

Scrum Flow

How we normally deliver functionality

What we know to start

Functionality / Problem solved

Eff

ort

expe

nded

(de

sign

, co

ding

, et

c)

Tracer Bullets

• A single piece of functionality is developed within the overall system structure and the development environment. This functionality works from the user interface, through all intermediate levels to the persistent data stores and back. This “tracer bullet” demonstrates that the development environment and operation environment work, allowing the team and users to refine their aim in future iterations1.

1 Andy Hunt and Dave Thomas (The Pragmatic Programmer)

Up Front Requirements

• Evidence indicates that no matter how detailed you try to flesh-out the requirements "up front", it still wont prevent more details from being discovered, and that you couldn’t have known them earlier before delving into design/implementation details

Ready, Fire, Aim, Aim, Aim…

*Ready, Fire, Aim* Ready…Aim… Aim… Aim… Aim… Fire… Aim,

aim, aim, aim…