Scrum A Radical New Approach to Project Management

Requirements for ScrumChanging needs for an agile development team

Glenn Gordon, PMP, Certified ScrumMaster

State of the World (Part 1)Project development has been a challenge for organizationsIssues include:Hide-bound bureaucracyInflexible control structuresDissatisfied stakeholdersPMI Founded in 1984IIBA Founded in 2003

State of the World (Part 2)Are We Agile Yet?Too often, Agile is a synonym for uncontrolled!No defined requirementsDevelopers working without plansTimeline not statedHeroic individual efforts requiredDissatisfied stakeholders

Scrum A Middle Path

4

Roles

Product Owner

Represents the interests of the stakeholdersResponsible for fundingDeterminesProject visionOverall Requirements (called Product Backlog)ROI ObjectivesPrioritization of Product Backlog ItemsState of CompletionThe Business Analyst may stand in for the true Product Owner

The TeamResponsible for developing functionalityTeams are:Self ManagingSelf OrganizingCross FunctionMust figure out how to turn Product Backlog into an increment of functionality within an iterationMay have specializations

The ScrumMasterResponsible for ProcessTeaches Scrum to TeamAdjusts Scrum to Organizational EnvironmentChairs Daily Scrum SessionsDoes not tell the team how to do their job!Is committed to the processDedicated to clearing obstaclesReliably chairs the daily Scrum

Artifacts

Product BacklogLists the requirements for System being builtProduct Owner is responsible for contents and prioritizationUsed to develop initial estimate for workThe Backlog is a living document

Product Backlog SampleFunctionEstimateDifficultyAdjustedSprint 1Sprint 2Sprint 3Sprint 4Configure Schedule8018080Manage Questions8018080Request Groups for Survey4014040Support Do Not Call401.56060Identify Next Phone Survey401.56060Administer Phone Surveys1201120120Export Surveys to CareAdvance8018080Generate Printed Surveys8018080Import Scanned Surveys8018080Generate Member Report1202240240760920260260160240

Sprint BacklogDefines tasks that a team has planned to turn Product Backlog into shippable product functionality.Tasks should:Take 4 to 16 hours to completeDeliver identifiable functionality

Sprint Backlog Sample

Burndown ChartCompares the work completed to planSprint is completed when remaining work is zeroDemonstrates a collision of reality with planning

Burndown Chart Sample

Sprint ProductEach Sprint should deliver a shippable productThe owner decides whether to ship the productIt is CRITICAL that each Sprint prepare product that is ready for usersEarly deployment adds early valueMaking Really Finished Stuff each Sprint means that the end of the project will not be spent productionalizing the output

Agile Development PrinciplesWork in short iterationsDeliver finished product in every iterationFocus on business prioritiesInspect and adapt

The Analyst's RoleThe project must have a VisionAll requirements are then compared to that vision

Epics and StoriesBoth describe FeaturesLarge features become EpicsEpics contain multiple StoriesStories driveEstimationPlanning DevelopmentTesting

Bad StoriesAs a user, I want to be able to easily navigate through my screens so that I can be more productiveAs an manager, I want to be able to run all kinds of reports so that we can get information to other departmentsAs a customer, I want to have all my needs met to increase my loyalty to the company.

Proper StoriesIn the form: As a , I want so that occurs.

As a prospect, I want to enter a minimal set of information about myself and generate a detailed quote so that I can determine if this product is appropriate for me.

INVEST StoriesLetterMeaningIIndependentNNegotiableVValuableEEstimableSSmallTTestable

The Process

Project InitializationGather High Level RequirementsPrepare Product BacklogGenerate FundingIdentify ScrumMaster and TeamDevelop Monthly Release Plan

Planning ProcessGather Feature ListDevelop StoriesEstimate effort for each storyPlanning Poker

Planning ScopeDo only the planning you need for the next horizonAt the start:A best guess at the overall scopeAn early alignment between stories and sprintsA deep dive into the next sprint drilling down into tasksAnalysis should align with development

Detailed Analysis Detailed analysis should be done just in timeYAGNI You Aren't Going To Need ItYou won't need 1/2 of your up front analysis You just don't know which half!Analysis and Design can be sprint tasksEither one sprint ahead of the developers or side by side with the developers

Planning a SprintBusiness drives what gets included in the SprintHistorical task throughput defines task volumeStories are the unit of inclusion

The SprintDevelopment project is broken into SprintsEach is 1 4 weeks longEach culminates in a Ready for Use Product

Sprint Planning MeetingProduct Owner and Team determine Product Backlog Items for next SprintBalance Owner Value with Team ability to deliverMeeting must be less than 8 hours!Goal is to WORK, not to think about working

Sprint Planning (cont.)First, choose the highest priority Product Backlog items that can be builtThe TEAM then Plans the SprintCreates the Task List

Daily Scrum15 minute daily meetingThree questionsWhat have you done since yesterday?What are you going to do today?What is in your way?All players are present, but issue resolution takes place offlineScrum Master updates the Task List and Burndown Chart

Daily Scrum NotesNever ask Percent Complete again!Tasks are DONE or NOT DONEDaily follow-up highlights task troublesTeam members know that tasks running for days will be followed up onTeam can add resources to a difficult task quickly, rather than identifying failures at the time

Sprint NotesEach Sprint delivers a FINISHED PRODUCTTasks includeDesignTestingDocumentationDeploymentEach Task produces an identifiable outputCompletion is verifiable

When is a Task Done?Code CompleteUnit tests written and executedIntegration testedPerformance testedDocumented (just enough)Business Owner Accepted

Sprint ReviewProduct is demonstrated to Product OwnerOther StakeholdersTeam is presentInformally, the team plans what should be done next

Sprint RetrospectiveScrum Master runs meeting with team to determine how:Improve the development processMore productivityMore enjoyable

Now, time for the next Sprint!

Be a ResourceRather than full designWork with the developer in a fast prototyping environment

Quality and Rapid DeliverySometimes the greatest corporate value is not the fastest deliveryBuilding a quality product that does not require extensive after deployment support takes more effortThe Agile practice of building software Unit Tests are implicitly included in the Scrum Process

Delivering Incremental ValueFocusing on delivering value early provides quick ROICustomers appreciate product in handFuture direction can be clarified

Key TakeawaysKeep tasks small Never ask percentage complete againDeliver FINISHED product each monthSave yourself from having to clean up loose endsMeet daily to discuss task statusFind products and blockages earlyAlways know application status

Other Agile PracticesTest Driven DevelopmentPair ProgrammingRefactor, Refactor, RefactorContinuous Integration40 hour week!Agreed upon Coding StandardsShared Code Ownership

Agile ResultsAt HealthNow92% fewer defects than traditional teamDelivered product on time; Traditional team slipped by 40%At Sabre Holdings (Travelocity)Productivity Gain: 42%Extreme Quality

See http://www.computerworld.com/s/article/91646/Sabre_takes_extreme_measures?taxonomyId=11&pageNumber=4

ResourcesAgile Project Management with ScrumKen SchwaberAgile Estimating and PlanningMike CohneXtreme Programming eXplainedKent BeckScrum DZone RefcardzMichael Jameshttp://refcardz.dzone.com/refcardz/scrum

Questions?

Thanks!Glenn Gordonglennmgordon@gmail.com (716) 239-1884