Introduction to Scrum

AgendaAgendaCommon Issues in Software DevelopmentCo o ssues So t a e e e op e tWhat is Scrum?The Scrum FrameworkThe Scrum Framework

2

Introduction to Scrum

COMMON ISSUES IN SOFTWARE DEVELOPMENT

Introduction to Scrum

SOFTWARE DEVELOPMENT

3

Problems Many Companies FaceProblems Many Companies Face

Time-to-market for products is too longTime to market for products is too long Project failure rate is unacceptably high Responding to change is difficult and costly p g g yCustomer involvement is weakSoftware quality is poorProductivity is extremely low Employee morale, drive and accountability is lowWidespread micromanagement is required Employee turnover rates are too high

4

Common Issues From a Business StandpointBusiness Standpoint

1. Our planning never yields precise results1. Our planning never yields precise results2. Quality is poor and an increasing issue with our customers3. Communication and visibility are lacking and I can’t set y g

expectations with my team (the “users”)4. I’m not able to make changes to scope easily without derailing

th ti j tthe entire project5. I don’t trust that my needs will be met

5

Common Issues From a Development Standpoint

1 Priorities and scope keep shifting based on the current

Development Standpoint

1. Priorities and scope keep shifting based on the current emergency and focus is totally lost

2. Unrealistic deadlines dictate poor architecture and design, as well as implementation choices

3. Production support issues pull developers away from new project work and timely enhancements to our product suiteproject work and timely enhancements to our product suite (too many balls in the air)

4. Poor historical decisions are being paid for now in the way we write code, rollout products, maintain systems, etc.

5. I don’t trust that my needs will be met

6

Working on theWrong Priorities is a WasteWrong Priorities is a Waste

Features and functions used in a typical system

Sometimes16% Rarely

19%16%

19%Often or always

used: 20%

Often13%

Never45%

Always7% R l

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

7% Rarely or never

used: 64%

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

7

The Multi-Tasking MythThe Multi Tasking MythEven adding a single project to your workload is profoundly debilitating by

Weinberg's calculation. You lose 20% of your time. By the time you add a third project to the mix, nearly half your time is wasted in task switching.

Quality Software Management: Systems Thinking by Gerald WeinbergQuality Software Management: Systems Thinking by Gerald Weinberg

8

Process Control

Defined Process Control: Empirical Process Control:• Every task must be completely

and unambiguously understood• Inputs are completely and

unambiguously defined

• The empirical model of process control provides and exercises control through frequent inspection and unambiguously defined

• When given a well-defined set of inputs, the same outputs are generated every time

adaptation• for processes that are

imperfectly defined• and generate unpredictable• and generate unpredictable

and unrepeatable outputs

Ill i f C t l D l t i ti t i ll d f lt t “d fi dIllusion of Control: Development organizations typically default to a “defined process control” based on an outdated notion of how software is built. Has anyone heard the “building software is like building a house” metaphor?

9

What We NeedWhat We NeedA way for customers to see and evaluate progress before its too y p glateA process that gives stakeholders more visibility, early and oftenA th t’ il d i t hA process that’s more agile and responsive to changesA process that allows development teams to “own” their commitmentsA process that accepts change but has enough rigor to yield a quality resultA process that helps us be much more predictableA process that helps us be much more predictableWe need more Trust!

10

Introduction to Scrum

WHAT IS SCRUM?Introduction to Scrum

11

Scrum isScrum is…Simple frameworkS p e a e oDisciplined approachCommitment-orientedCommitment orientedResults-orientedCollaborative effortCollaborative effortEmpirical process

“Scrum is not a methodology – it is a pathway” (Ken Schwaber))

12

What Is Scrum Being Used For?What Is Scrum Being Used For?Large-scale enterprise software projects g p p jConsumer software productsUS FDA-approved software for X-Rays, MRIsHigh availability systems (99.9999% uptime)Financial payment applications Large database applications Embedded systems CMMi L l 5 i tiCMMi Level 5 organizations Multi-location development Sustaining and Maintenance ProjectsSustaining and Maintenance Projects Non-software projects

13

Scrum Shifts the DriversScrum Shifts the Drivers

Traditional Project ScrumTraditional Project ScrumThe plan creates cost / schedule

estimates

The vision creates feature estimates

Fixed

ValueFeatures Cost Schedule

Plan

Value Driven

EstimatedDriven

Cost Schedule Features

14

Benefits of ScrumBenefits of ScrumScrum allows teams of people to develop complex Sc u a o s tea s o peop e to de e op co p eproducts in environments of uncertainty and change.Scrum is a simple but powerful framework for teams

d t t i t d d t th d t iand customers to inspect and adapt as the product is produced.Scrum provides a high degree of clarity andScrum provides a high degree of clarity and transparency to everyone involved – team, customer, management, and others.Scrum rapidly surfaces dysfunction, and enables teams and organizations to continuously improve their effectivenesseffectiveness.

15

Typical Results with ScrumTypical Results with Scrum

3rd Annual Survey: 2008 “The State of Agile Development” Conducted June-July 2008 By VersionOne

2319 Completed Surveys80 Countries RepresentedConducted June-July 2008 By VersionOne 80 Countries Represented

16

Introduction to Scrum

THE SCRUM FRAMEWORKIntroduction to Scrum

17

3 Facets of Scrum3 Facets of Scrum

Roles(Wh )

Practices(How)

Artifacts(What)

Product Owner SprintS

Product Backlog

(Who) (How)(What)

TeamScrum Master

Sprint Planning MeetingDaily Standup

BacklogSprint BacklogPotentially Daily Standup

Sprint ReviewSprint

PotentiallyShippable Product

Sprint RetrospectiveSprint

Burndown Chart

18

Overview of Scrum FrameworkOverview of Scrum FrameworkRoles

Artifacts & Practices

19

Role:

Product OwnerProduct OwnerOwns the vision of what should be produced to achieve O s t e s o o at s ou d be p oduced to ac e ebusiness successManages ROI through prioritization and release plansGets input from customers, end-users, team, managers, stakeholders, executives, industry experts when crafting the visionwhen crafting the visionTurns input into a single list of what should be produced, prioritized based on business value and riskp , pOwns the Product Backlog

“The Product Owner’s focus is ROI. The Product Owner directs the project, sprint by sprint to provide the greatestsprint by sprint, to provide the greatest ROI and value to the organization.”

20

Role:

TeamTeamOwns the production and engineering processO s t e p oduct o a d e g ee g p ocessCross-functional - it has all the skills to produce the finished productSelf-organizing and self-managing - it is responsible for making a commitment and managing itself to hit the goals (or get as close as it can)goals (or get as close as it can)Authority to do whatever is necessary to meet it’s commitmentThe ideal team size in Scrum is 7 people +/- 2

“The Team is responsible for managing itself and has the full authority to do anything to meet the sprint goal within theanything to meet the sprint goal within the guidelines, standards, and conventions of the organization and of Scrum.”

21

Role:

Scrum MasterScrum MasterA new leadership rolee eade s p o e

It can be played by an existing person (such as a former Project Manager or team-member).

Serves the team Helping remove any and all impediments that surface

Protects the team Teaches and guides the team’s use of ScrumFacilitates – doesn’t “manage” (direct) the team

“The Scrum Master is responsible for the success of the project, and helps increase the potential for success by helping the Product Owner select the most valuable backlog items and by helping the Team turn that backlog into functionality.” 22

Practice:

SprintSprintThe team works for a fixed period of time.e tea o s o a ed pe od o t eSprints are typically 1-4 weeks in length. Some recommend starting Scrum with 2-week Sprints.Sprints occur one after another, without any down-time between them. Working at a sustainable pace is very important to avoid team burn outimportant to avoid team burn-out.Team and Product Owner decide the Sprint length in advance.

23

Practice:

Sprint ScopeSprint ScopeTime frame and commitments do not changee a e a d co t e ts do ot c a ge

Do not adjust schedule—end date of Sprint is fixedThe team’s commitment is for length of SprintThe team s commitment is for length of SprintEnables the team to make and keep commitmentsGives the team focus and stability during the SprintGives the team focus and stability during the SprintTrains Product Owner to clearly think through what is on the Product BacklogIn special cases, Product Owner can direct the team to terminate the Sprint prematurely and start a new one.

24

Practice:

Sprint ScopeSprint ScopeFuture workutu e o

Product Owner can make any changes they want to the Product Backlog before the start of the next Sprint.Product Owner can add, remove, reorder, or change backlog items. Product Owner can also ask the team to re-implement work that has already been completed.

25

Artifact:

Product BacklogProduct BacklogSingle master list of features, functionality, and other g ywork requiredPrioritized based on business value and risk, in the judgment of the Product Ownerjudgment of the Product OwnerItems at the top of the list will be completed by the team first and should have more detail than lower priority itemsfirst and should have more detail than lower priority itemsConstantly being revised by the Product Owner, to maximize the business success of the team’s effortsProduct Backlog Items vary in size (typically 2-3 people, 2-3 days).

26

Artifact:

Product Backlog ExampleProduct Backlog ExampleTitle Status Priority Estimate ReferenceMoney Market Access (BMG) checking data into FMG DW(5275) In Progress Critical 1.00 SCR 5275Develop Sales Rep Dimension CriticalCreate Cognos catalog subject area - Dividends In Progress Critical 30.00Create Cognos catalog subject area - SAM In Progress Critical 30.00Create Cognos catalog subject area - SAD In Progress Critical 30.00Analyze Call Center Reporting High SCR 5276Modify CARMA to maintain WFFD terms & conditions High 52.00 SCR 52712003 and 2004 AUM differences clean-up High 0.00 SCR 5166

ProductBacklog

Items

Unknown Sponsor / Strategy in FMG DW for Managed Accounts High 0.00 SCR 5165Create effective dating for Territory Maintenance High 215.00Create territory overrides High 215.00Populate FMG-DW with territory information High 215.00Prepare for production readiness High 100.00Administrator group access on Windows servers High

PriorityOrder

Sybase Upgrade - UAT In Progress High 5.00Managed Account Suspension Item 2 - Copy Back High 0.00MAPS: Error - Rep info missing from Rep-EOM-CD HighDocument overall data flow for populating the D Sales Rep dimension In Progress High 7.00Design a Code dimension In Progress High 20.50Design a CRM HQ Company dimension In Progress High 7.50

High-levelEstimate

Design a CRM Company dimension In Progress High 7.50Design a Channel dimension In Progress High 9.50Design an integrated Territory dimension In Progress High 10.50VAS/PowerBroker MediumHusky and FTP100 Tech Refresh MediumUpdate User Created SQL Process Low SCR 5271

27

User StoriesUser Stories“…are promises for an ongoing conversations”a e p o ses o a o go g co e sat o sMike Cohn’s User Story template:“As a <Some Role>I want <Some Business functionality>So that <Some Business Value or Justification>

For Developers, the “I want” clause is what counts,F P d t O th “ th t” l i h t tFor Product Owners, the “so that” clause is what counts

28

Types of User StoriesTypes of User StoriesEpic

High level may contain only 2 of 3 components of user storyHigh level may contain only 2 of 3 components of user storyAs a <user role> I want an application, so <business justification>

Used as place holders to create product roadmapThemes – in betweenStory – I.N.V.E.S.T. criteria

IndependentIndependentNegotiableValuableEstimableEstimableSmallTestable

User Story ExampleUser Story ExampleAs Tim (tired morning person), I want my usual s (t ed o g pe so ), a t y usuaKwikoffee so that I can get to work and without rushing.“Done” when

A simple cup can be ordered from the kioskAutomated tests written for all UATsUser documentation written for new/modified functionality

30

Definition of DoneDefinition of DoneDefined by both the Product Owner and the Teame ed by bot t e oduct O e a d t e eaEveryone agrees on the definition of doneGoalsGoals

Deliver complete “slices” of the systemIterate over robustnessIterate over robustness

ToolsSolid engineering practicesSolid engineering practicesSolid engineering infrastructure

31

Practice:

Sprint Planning MeetingTeam selects what it will commit to deliver by the end of

Sprint Planning Meetingea se ects at t co t to de e by t e e d o

the SprintTeam creates a task-level plan for how they will deliverTeam creates an initial assignment of tasksTeam compares total estimated task hours with total estimated available hours, to make sure the commitment is reasonableEveryone on the team takes part regardless of role andEveryone on the team takes part, regardless of role and experience-level

32

Practice:

Sprint Planning MeetingSprint Planning MeetingProduct Owner must not pressure the team into oduct O e ust ot p essu e t e tea tocommitting to more than they think is doable.Managers may initially be concerned that their team might

d itunder-commit. Many teams are initially concerned about the perception of the amount of work being completed so they overof the amount of work being completed, so they over-commit.In reality, most teams have the opposite problem: it may y, pp p ytake them several Sprints to learn to not over-commit.

33

Practice:

Sprint Planning MeetingSprint Planning MeetingExample of Agendaa p e o ge da

1:00 – 1:30. Product Owner goes through the sprint goal and summarizes product backlog.1:30 – 3:00. Team breaks down items and estimates time. Product Owner updates priorities as necessary.3:00 – 4:00. Team selects the backlog items to be included in the sprint and makes commitment to Product Owner.

34

Artifact:

Sprint BacklogSprint BacklogComplete list of tasks required to meet the sprint goals Co p ete st o tas s equ ed to eet t e sp t goa sand committed product backlog itemsTasks include detailed estimate created by the teamTeam tracks effort remaining to complete each taskConstantly being revised by the Team, to maximize achievement of the sprint goalTasks vary in size but no larger than 16 hours

35

Artifact:

Sprint Backlog ExampleBacklog Item / Defect Task Owner Status

Detail Estimate Done To Do

Confirm business rules Zigler, Al,Carter, Tammy Checked Out 4.00 3.50 2.00Update Search results integration tests Minor, Brian 4.00 4.00C l t b i l lid ti G J h 5 00 5 00

Complete development of Office Merge screens

Sprint Backlog Example

Complete business rule validation Grayson, John 5.00 5.00Review business rule validation Zigler, Al,Minor, Brian,Grayson, John,Carter Checked Out 5.00 2.00 3.00Review business rules with PO Zigler, Al,Carter, Tammy Done 2.00 1.00 2.00Develop Onyx table update Grayson, John Checked Out 6.00 2.00 4.00Add integration tests for Office merging Grayson, John 6.00 6.00Procedure test script Grayson, John 6.00 6.00Peer review Minor, Brian,Dupont, Jason,Grayson, John 3.00 3.00Review database changes Grayson John Lin Kim Done 1 00 1 00 0 00

Backlog Items

Review database changes Grayson, John,Lin, Kim Done 1.00 1.00 0.00Add Effective date - logical/physical models Lin, Kim 1.00 1.00Add Effective date - implementation Lin, Kim 1.00 1.00Update caliber Lemke, Linda 1.00 1.00Review requirements - Onyx batch impacts/bShavasi, Sudhir Checked Out 2.00 2.00 0.00Review requirements - Onyx batch impacts/bZigler, Al,Carter, Tammy,Shavasi, Sudhir Checked Out 3.00 1.00 2.00Update test scripts Shavasi, Sudhir 3.00 3.00Review test scripts Zigler, Al,Lemke, Linda,Carter, Tammy,ShavChecked Out 4.00 5.00 2.00

Tasks

p g , , , , , y,Test data prep Shavasi, Sudhir 6.00 3.00 3.00Execute component testing Shavasi, Sudhir 16.00 16.00Issue resolution Minor, Brian,Grayson, John,Shavasi, Sudhir 12.00 12.00

Environment Build Create list of database for Rlse 1.0 Lin, Kim Done 1.00 1.00 0.00Review list of Release 1.0 changes Minor, Brian,Lemke, Linda,Grayson, John,Lin, Kim,Carter, Tammy 5.00 2.00 4.00Re-apply Release 1.0 changes - DEV Lin, Kim 4.00 1.00 3.00Implementation Release 1.0 in local FMG Van Camp, Fred,Lin, Kim 2.00 2.00

User Training Manual Define scope, audience, and deliverables Lemke, Linda Checked Out 4.00 1.50 4.00Document approach Lemke, Linda Checked Out 6.00 6.00Draft Format of Manual Lemke, Linda 6.00 6.00Draft Content Lemke, Linda 10.00 10.00Review approach with product owners Lemke, Linda 4.00 4.00Review & Update content with product owne Lemke, Linda 3.00 3.00

36

Practice:

Daily StandupDaily StandupA short meeting daily to update each other on progress s o t eet g da y to update eac ot e o p og essand surface impedimentsStrictly time-boxed to 15 minutes3 questions: what was done since last meeting, what will be done by next meeting, and any issues/impedimentsScrum Master notes issues/impediments, and afterwards helps resolve themOthers can attend the meeting if the team invites themOthers can attend the meeting if the team invites them, but they do not speak. This meeting is not for monitoring the team.

37

Artifact:

Burndown & Burnup ChartsBurndown & Burnup ChartsEach day, the team updates simple charts that show ac day, t e tea updates s p e c a ts t at s oprogress towards their Sprint goal.The Burndown Chart graphs the total hours left for all t ktasks. The Burnup Chart graphs the total number of backlog items completed in the Sprintitems completed in the Sprint.These charts enable the team to successfully self-manage and deliver what they committed to by the end of g y ythe Sprint.

38

Artifact:

Burndown & Burnup Charts ExampleBurndown & Burnup Charts Example

Agile V Scorecard

39

Artifact:

Potentially Shippable ProductPotentially Shippable ProductThe goal for the team is to complete 100% of what they e goa o t e tea s to co p ete 00% o at t eycommitted to, ideally an increment of Potentially Shippable Product at the end of each Sprint.F ft thi f ti lit th t h bFor software, this means functionality that has been designed, fully implemented, and fully tested, with no major defects.jFew teams can produce Potentially Shippable Product from Sprint 1, but each Sprint they work to get closer to thi lthis goal.

40

Practice:

Sprint Review (Demo)Sprint Review (Demo)Performed at the end of each Sprinte o ed at t e e d o eac Sp tProduct Owner, Team, Scrum Master, and Stakeholders come together and see a demo of what the team has

d dproducedProduct Owner gathers feedback from everyone on the ways to improve what has been builtways to improve what has been builtFeedback is incorporated into the Product Backlog

41

Practice:

Sprint RetrospectiveSprint RetrospectiveCritical for continuous improvement of team effectivenessC t ca o co t uous p o e e t o tea e ect e essMethod for identifying and addressing critical problemsRetrospective meeting requires the Team, ProductRetrospective meeting requires the Team, Product Owner, and Scrum MasterFocuses on 3 questions:

1. What worked well? 2. What needs improvement? 3. What action items do we implement in the next sprint

42

Practice:

Sprint RetrospectiveSprint RetrospectiveExample of Agendaa p e o ge da

1:00 – 1:30. Review the commitment results for Sprint1:30 – 2:00. Brainstorm everything that worked well1:30 2:00. Brainstorm everything that worked well2:00 – 2:30. Brainstorm areas of improvement2:30 – 3:00 Brainstorm action items to address areas2:30 3:00. Brainstorm action items to address areas of improvement3:00 – 3:30. Select action items to implement next sprint and commit to improve

43

Practice:

Sprint RetrospectiveSprint RetrospectiveWhat went well?

All code was delivered ahead of schedule which helped in testing progress.Code Review’s addedCode Review s addedMore continues development timeRequirements Update continuedDevelopers were able to take others tasks to help completion based on obstacles that came

What can we improve?Revisit the meeting time of the huddle gWho closes stories/ tasksDefines Goals in AdvanceRequirements delay based on capacity and change in directionWould like to continue to focus on collaboration between dev/req reviewRequirements still key and needed. Difficult to determine focus split on documentation for Too many storiesToo many storiesDifficult in switching views in VersionOneCan we go to 4 week iteration?Stories should not be added after the planningCapacity concern with business partner time also. Might need to have multiple days to digest and review with other business counter parts.

Action ItemsImplement code reviewsHold more design meetings, reviews with the Business OwnerAdd Business owner tasks to VersionOne

44

Typical Project LifecycleTypical Project LifecycleProduct /Project

Planning Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

Release A Release B

SprintPlanning

Sprint

SprintPlanning

Sprint

SprintPlanning

Sprint

SprintPlanning

Sprint

SprintPlanning

Sprint

SprintPlanning

SprintReview &

RetroReview &

RetroReview &

RetroReview &

RetroReview &

RetroReview &

Retro

45

Introduction to Scrum

QUESTIONSIntroduction to Scrum

46