• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introduction to scrum

Introduction to scrum







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Introduction to scrum Introduction to scrum Presentation Transcript

    • A Brief Introduction to Scrum An Agile Methodology by Craig D. Wilson MS, PMP, CSM Matincor, Inc. Information Technology Management Consulting
    • Presentation Outline Introduction to Scrum Origins of Scrum Definitions & Principles Benefits & Risks © Matincor, Inc. 2 of 44Ver. 2 2009
    • Caveats & DisclaimersFocused on “core” Scrum as defined in“ScrumGuide” by Ken Schwaber and otherintroductory Scrum textsPresentation is a summary of a two-day class –all topics are touched upon but summarized andsimplifiedScrum and the Scrum community are evolving -many weaknesses have been or are beingaddressed © Matincor, Inc. 3 of 44 2009
    • An “agile” methodology Supports the Agile Manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a planCopyrighted by the following: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas © Matincor, Inc. 4 of 44 2009
    • Agile Methodologies Extreme Programming MSF for Agile Software Development Crystal ScrumFeature Driven Development Adaptive Software Development Dynamic Systems Development Method © Matincor, Inc. 5 of 44 2009
    • Why Talk About Scrum?PopularPowerfulEasy to learn But….. misunderstandings abound © Matincor, Inc. 6 of 44 2009
    • “All models are wrong, some are useful…..” George Box, industrial statistician © Matincor, Inc. 7 of 44 2009
    • Popularity of the Scrum ModelBasic principles are easy to understandTechnology and tool agnosticBuilt on several time-tested techniquesUtilizes team-of-peers managementapproach © Matincor, Inc. 8 of 44 2009
    • History of ScrumInspired from approach defined in 1986 byH. Takeuchi and I. NonakaTerm “scrum” used in “Wicked Problems,Righteous Solutions” by DeGrace andStahl in 1991Used as a methodology name in the book“Agile Software Development withSCRUM” by K. Schwaber and M. Beedlepublished in 2001. © Matincor, Inc. 9 of 44 2009
    • A Rugby Scrummage © Matincor, Inc. 10 of 44 2009
    • Definition of Scrum“Scrum…is a framework within which youcan employ various processes andtechniques…within which complex productscan be developed” -Ken Schawber, ScrumGuide, May 2009 © Matincor, Inc. 11 of 44 2009
    • Scrum PrinciplesTime-boxesCross-functional teamsOpen communications Within team With stakeholdersPriorities set by Product OwnerDemonstrable resultsResponsive to change © Matincor, Inc. 12 of 44 2009
    • The Process 24 hours 2-4 weeks Image used by permission Mountain Goat Software Copyright 2005 © Matincor, Inc. 13 of 44 2009
    • Scrum TermsTeam Meetings ScrumMaster Daily scrum Scrum Team Planning Product Owner Review Users & Stakeholders RetrospectiveSprint BurndownBacklog Chart Product Velocity Sprint © Matincor, Inc. 14 of 44 2009
    • The TeamScrumMaster Not “command & control” project manager Process coach and team facilitator Remover of roadblocksScrum Team Individuals responsible for the Sprint results Mix of skills representing multiple disciplines Usually 6-8 individualsProduct Owner Individual responsible for product Responsible for product profitability (ROI) Adjusts feature list and priorities for each Sprint Accepts or rejects work resultsUsers & Stakeholders Interested in results but not responsible for deliverables © Matincor, Inc. 15 of 44 2009
    • The SprintTime boxed effort Usually 2 weeks to 1 month Can be longer or shorterDefined workload No changes once Sprint is begun If workload changes, Sprint restartedBegins with Planning MeetingEnds with demonstrable Release © Matincor, Inc. 16 of 44 2009
    • Product BacklogAll features and functions for final productMay be subdivided into releasesPrioritized by Product OwnerInitial backlog is established and releases aredefined prior to start of SprintsProduct backlog is reviewed and updatedthroughout the projectTime must be allotted during Sprints to allow forthis activity © Matincor, Inc. 17 of 44 2009
    • Sprint BacklogFeatures and functions targeted for a singleSprint Frequently broken down into User Stories; especially if function is complexMay include technical requirements or objectives e.g.; database design, UI standards, architecture documentation © Matincor, Inc. 18 of 44 2009
    • MeetingsSprint Planning Sprint goal and functionality objectives Sprint tasks identifiedDaily ScrumSprint ReviewSprint Retrospective Scrum meetings are time-boxed and occur on a regular schedule! © Matincor, Inc. 19 of 44 2009
    • Sprint PlanningProduct Owner and TeamReview of Product BacklogProduct Owner provides definition and details offeatures and functionsNegotiation of what will be in SprintMay identify new Product Backlog needsResults in Sprint Goals © Matincor, Inc. 20 of 44 2009
    • Sprint Task DefinitionsSprint Team meetingImmediately follows Sprint PlanningBreaks work into tasks 4-16 hours of effort each Identifies interdependenciesResults in Sprint BacklogTasks are prioritized by team © Matincor, Inc. 21 of 44 2009
    • Daily ScrumStandup 15 minute meetingEach team member answers 3 questions: What have you done since the last meeting? What will you do before the next meeting? What is preventing you from accomplishing your tasks?For benefit of other team members Not a “status report” to the ScrumMaster © Matincor, Inc. 22 of 44 2009
    • Sprint ReviewResults of Sprint are demonstrated to ProductOwnerOwner accepts or rejects resultsResults are input to: Next Sprint Planning meeting Sprint Retrospective © Matincor, Inc. 23 of 44 2009
    • Sprint RetrospectiveMeeting with Sprint Team May include Product OwnerProcess review and modificationLessons learned applied in following Sprints © Matincor, Inc. 24 of 44 2009
    • Scrum Estimation TechniqueTeam effort Only those doing the workReal time Delphi methodEvaluate relative “effort size” of functions Factors may include complexity, effort, uncertaintyAssign relative “work effort value” to eachfunctionTrack progress against effort estimate © Matincor, Inc. 25 of 44 2009
    • Delphi ProcessDeveloped by Rand Corporation in late 1940’sDocumented in software development in 1970’s by BarryBoehm and John Farquhar Defined as “Wideband Delphi” due to more interactive discussionsIn Scrum Team members evaluate and compare a list of functions Next, compare opinions of relative effort required Work to an agreement on estimates Occurs during backlog review and updates © Matincor, Inc. 26 of 44 2009
    • Relative EstimationDefine relative complexity & effort Much larger, larger, equal, smaller, much smaller Several “fun” techniques (Number of pizzas, T-shirt sizes, buckets, Planning Poker®)Assign numeric value to each category Numbers have no intrinsic value; only relative valueEstimators discuss results and continuere-estimating until everyone in agreementResults in work points © Matincor, Inc. 27 of 44 2009
    • Using Work PointsAt end of Sprint total work points achieved byadding estimates for all accepted functionsTrack number of work points earned in eachiteration to determine Product Backlog Burndown VelocityDifficult to carry work point estimations over toother projects Different teams, tools, technologies, etc. © Matincor, Inc. 28 of 44 2009
    • BurndownMeasurement of accomplishments Product Backlog Burndown Sprint Task BurndownBurndown Chart Burn Down Rate 300 250 200 150 100 50 0 1 2 3 4 5 6 7 © Matincor, Inc. 29 of 44 2009
    • VelocityCompare Velocity to total Estimated WorkPoints for Product Backlog to estimateproject durationNeed several Sprints to determine team’svelocitySame technique is used to estimate SprintBurndown Track tasks instead of functions © Matincor, Inc. 30 of 44 2009
    • Benefits of ScrumTargets Product Owner’s functions-of-valueFocus on team communications Frequent and ready access to knowledge Co-location improves communicationsFrequent demonstrations for early feedbackfrom stakeholdersTeam spirit and camaraderieSense of accomplishmentQuality of product © Matincor, Inc. 31 of 44 2009
    • But keep the following in mind….. © Matincor, Inc. 32 of 44 2009
    • Sprint ProcessSprint is not a “mini-waterfall”Must result in quality, demonstrablefunction(s) of value to Product Owner Beware of defect build-up (aka technical debt)Sprints will include requirementsclarification, development, and testing Sprints may include architectural design Full regression testing may parallel next Sprint © Matincor, Inc. 33 of 44 2009
    • A Phase Is Not A SprintAnalysis Coding Testing Analysis Coding Testing Analysis Coding Testing Time-boxed coding phases following on the footsteps of each other is not Scrum and violates several principles of the methodology. © Matincor, Inc. 34 of 44 2009
    • Team Roles – ScrumMasterLacks many Project Manager responsibilities asdefined by Project Management Body ofKnowledge Someone needs to perform these responsibilities May be PM overseeing several related Scrum teamsLacks authority given to some Project Managers– which may be needed on large scale ordifficult projects © Matincor, Inc. 35 of 44 2009
    • ScrumMaster CertificationCurrently achieved by attending 2-day lectureprovided by Certified Scrum TrainerEffective October 1, 2009 must also pass aCertified ScrumMaster online certification exam © Matincor, Inc. 36 of 44 2009
    • Team Roles – Product OwnerRole filled by prime user or sponsor Responsible for resulting product and its ROIRole may be supported by Business Analyst Representing the interests of users and stakeholders Must be careful not to become a wall between users and Sprint Team Should be a “communication enabler” Facilitate communications between users and team © Matincor, Inc. 37 of 44 2009
    • Team Roles – Team MembersChoose their own tasks Not assigned by Scrum Master Works better with a “process mature” teamBeware “task hogs” who Take on more than they can handle Grab the best tasks for themselvesSome may perceive themselves as filling atraditional role rather than co-owner of SprintRelease “I’m a QA guy. Call me when you’re ready to test…….” © Matincor, Inc. 38 of 44 2009
    • Intense IterationsFull team is “always on” during a SprintMust be cautious of team burnoutLimit overtimeSet a sustainable pace © Matincor, Inc. 39 of 44 2009
    • Project Duration EstimatesIn order to estimate project duration you need toknow Full inventory of Product Backlog Know enough about each function to perform estimation techniqueAddress this by using Product Releases Break large projects in to several production releasesDo not rely solely on the Delphi estimationtechnique for project duration estimates Experience and common sense should not be ignored © Matincor, Inc. 40 of 44 2009
    • Product EngineeringScrum does not address product engineering For software development you will need a software engineering process such as Object Oriented Analysis & DesignMay benefit by adding methods that are morefocused on software creation Extreme Programming (XP) © Matincor, Inc. 41 of 44 2009
    • Target FixationBeware team target fixation If goal is velocity and burn-down, quality could sufferFocus may be on developing torequirements and a miss on getting therequirements right Product owners may not always know “right” requirements. Still need effective research, analysis, process re-engineering, etc. © Matincor, Inc. 42 of 44 2009
    • Product BacklogIn “core” Scrum, this is very poorly defined Assumes Product Owner has, or can, fully define the requirements Does not address requirements discovery, non- functional requirements, or requirements analysisProduct Backlog requires on-going “grooming”and this activity must be part of Sprints Breakdown functions into User Stories Provide greater detail for upcoming Sprints © Matincor, Inc. 43 of 44 2009
    • Suggestions For Further StudyScrum Alliance www.scrumalliance.orgMountain Goat Software Mike Cohn is the founder and great presenteron the topic! www.mountaingoatsoftware.com30-Day Blitz Another time-boxed methodology:www.michaelhugos.com/30-day_Blitz.htmlCase study: “Issues and Challenges of Agile Software Development withScrum” by Juyun Cho, Colorado State University More presentations by Craig D. Wilson www.matincor.com © Matincor, Inc. 44 of 44 2009