• Save
Scrum Awareness 2.0.1
Upcoming SlideShare
Loading in...5
×
 

Scrum Awareness 2.0.1

on

  • 1,023 views

a 3-hour Scrum Awareness course

a 3-hour Scrum Awareness course

Statistics

Views

Total Views
1,023
Views on SlideShare
1,021
Embed Views
2

Actions

Likes
3
Downloads
0
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Demonstrateoneburndownchart. Talk aboutdifferentapproaches to theuseofburndowncharts, for examplethesetwodifferentapproaches:A burndownchartcovering all tasks for oneuser story or use caseA burndownchartcovering all tasks for one sprintDemoshould be simple and quick, ca 5 minutes?
  • Studyofestimate: ^Molokken-Ostvold, K. Haugen, N.C. (13 April 2007). "Combining Estimates with Planning Poker--An Empirical Study". IEEE. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4159687. Retrieved on 2008-02-01. (SimulapåLysaker)
  • Print andgive to participants
  • Printout and give to participants
  • A semi-largeexercise, practicalexercise, typicallythe team buildsomething. Facilitator is ProductOwner, must provide materials and backlogwith story pointsIncludesestimating (team), building (team), requirementchange (PO), story pointchange (PO)Facilitatorprovides materials and backlog, completewith story points. ---”Town Area”: A table or marked area onthefloor (brownpaper?). Props: Scissors, paper (A4), tape, ruler
  • Specsofbuildingsonearlier slide

Scrum Awareness 2.0.1 Scrum Awareness 2.0.1 Presentation Transcript

  • ScrumAwareness 2.0.1
    Ådne Brunborg
    <date>
  • Who am I?
    Ådne Brunborg
    Senior Consultant at Capgemini since march 2005
    Over 11 yearsexperience as…
    Developer
    Architect
    Team Leader
  • Audienceexpectations?
  • Aim
    This courseaims to provide a basicunderstandingof Agile methods, in particularScrum as a method, itsrelevance and mindset, and practicaluseofScrum in projects
    Itsprimaryaudience is developerswithlittle or nounderstandingofScrum
  • Contents
    Part 1: Agile and Scrum
    10 min break
    Part 2: Agile Estimating and Planning
    Part 3: ScalingScrum
    10 min break
    Part 4: Exercise
  • Contents
    Part 1: Agile and Scrum
    10 min break
    Part 2: Agile Estimating and Planning
    Part 3: ScalingScrum
    10 min break
    Part 4: Exercise
  • Manifesto for Agile Software Development
    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan
    That is, while there is value in the items on the right, we value the items on the left more.
    www.agilemanifesto.org
  • Scrum
  • Scrum
    Scrum, as a holistic approach in which phases strongly overlap and the whole process is performed by one cross-functional team across the different phases, is comparable to rugby, where the whole team "tries to go to the distance as a unit, passing the ball back and forth“
    (from “The New New Product Development Game” by Hirotaka Takeuchi and IkujiroNonaka )
  • Scrum
    Wikipedia: ”Scrum is an iterative incremental process of software development commonly used with agile software development.”
  • Scrum
    Wikipedia: ”Scrum is an iterative incremental process of software development commonly used with agile software development.”
    Definitionsvary: ”Its a method… it’s not a methodit’s a process… it’s not a processit’s a framework… it’s not a frameworkit’s a method… etc”
  • Scrum
    Wikipedia: ”Scrum is an iterative incremental process of software development commonly used with agile software development.”
    Definitionsvary: ”Its a method… it’s not a methodit’s a process… it’s not a processit’s a framework… it’s not a frameworkit’s a method… etc”
    Butthat is not important!
  • Scrum in 100 words (or less)
    Scrum is an Agile process focuses on delivering the highest business value in the shortest time
  • Scrum in 100 words (or less)
    Scrum is an Agile process focuses on delivering the highest business value in the shortest time
    The business sets the priorities. The developers self-organize to determine best to deliver the highest priority features
  • Scrum in 100 words (or less)
    Scrum is an Agile process focuses on delivering the highest business value in the shortest time
    The business sets the priorities. The developers self-organize to determine best to deliver the highest priority features
    It utilizes rapid and repeated inspection of work products
  • Scrum in 100 words (or less)
    Scrum is an Agile process focuses on delivering the highest business value in the shortest time
    The business sets the priorities. The developers self-organize to determine best to deliver the highest priority features
    It utilizes rapid and repeated inspection of work products
    Every two to four weeks “anyone” can see real working product increments – which may be released to customers
  • Scrum in 64 words
    Scrum is an Agile process focuses on delivering the highest business value in the shortest time
    The business sets the priorities. The developers self-organize to determine best to deliver the highest priority features
    It utilizes rapid and repeated inspection of work products
    Every two to four weeks “anyone” can see real working product increments – which may be released to customers
  • ScrumOverview
  • ScrumOverview
    ScrumArtifacts
    ScrumProcess
    ScrumRoles
  • The Artifacts
    ProductBacklog
    a prioritized list of high level requirements
  • The Artifacts
    ProductBacklog
    a prioritized list of high level requirements
    Sprint Backlog
    a list of tasks to be completed during the sprint
  • The Artifacts
    ProductBacklog
    a prioritized list of high level requirements
    Sprint Backlog
    a list of tasks to be completed during the sprint
    BurndownChart
    a progress chartmeasuring ”estimatedhoursremaining”
  • The Artifacts
    ProductBacklog
    a prioritized list of high level requirements
    Sprint Backlog
    a list of tasks to be completed during the sprint
    BurndownChart
    a progress chartmeasuring ”estimatedhoursremaining”
    ScrumBoard
    making it all visible
  • ScrumBoardexample
  • Live Demo: BurndownChart
  • The Process
    DailyScrum
    15 minutes STANDING; each team memberanswer 3 questions:
    What have youdonesinceyesterday?
    What do you plan to do today?
    Do you have any impediments?
  • The Process
    DailyScrum
    15 minutes STANDING; each team memberanswer 3 questions:
    What have youdonesinceyesterday?
    What do you plan to do today?
    Do you have any impediments?
    Sprint
    An iteration, 2-4 weeks
    No changes in the Sprint Backlog during thisperiod!
  • The Process
    DailyScrum
    15 minutes STANDING; each team memberanswer 3 questions:
    What have youdonesinceyesterday?
    What do you plan to do today?
    Do you have any impediments?
    Sprint
    An iteration, 2-4 weeks
    No changes in the Sprint Backlog during thisperiod!
    Sprint Retrospective – ”inspect and adapt”
    At end of a Sprint, 30 minutes to 4 hours
  • Questions?
  • Exercise 1: The DysfunctionalScrum
    8 volunteers
    Each person willget a cardwithinstructions
    One person will be theScrum Master
    The team willperform a DailyScrum, witheach person actingoutthe given instructions
  • Exercise 1: The DysfunctionalScrum: ExerciseRetrospective
    Whatthecardssaid
    Be very vague about what you did yesterday.
    Attempt to distract the people next to you
    Get really technical about what you did or are going to do so nobody on the team understands your jargon.
    You’ve been struggling with the same task for the last 5 days.
    Try and talk for as long as possible about what you did yesterday or are going to do today.
    Always interrupt others when they are talking.
    • Immediately leave the room. Then, return (“turn up late to the Daily Scrum”) and act uninterested.
  • Pigs and Chickens
  • The PigRoles
    The Team
    developers, designers, testers…
    responsible for deliveringtheproduct
  • The PigRoles
    The Team
    developers, designers, testers…
    responsible for deliveringtheproduct
    The Scrum Master
    responsible for facilitatingtheScrumprocess
  • The PigRoles
    The Team
    developers, designers, testers…
    responsible for deliveringtheproduct
    The Scrum Master
    responsible for facilitatingtheScrumprocess
    The ProductOwner
    responsible for maintaining the Product Backlog by representing the interests of the stakeholders ("customers").
  • The ChickenRoles
    End Users
    For whomthe software is built
  • The ChickenRoles
    End Users
    For whomthe software is built
    Stakeholders (customers, vendors )
    The business side
  • The ChickenRoles
    End Users
    For whomthe software is built
    Stakeholders (customers, vendors )
    The business side
    Management
    The organisation side
  • Questions?
  • ScrumPrerequisites
    Understandingofthemethod and itsprinciples
    (this is whyweareheretoday)
  • ScrumPrerequisites
    Understandingofthemethod and itsprinciples
    (this is whyweareheretoday)
    Customeravailable during theproject
  • ScrumPrerequisites
    Understandingofthemethod and itsprinciples
    (this is whyweareheretoday)
    Customeravailable during theproject
    Culture for opencommunication
  • ScrumPrerequisites
    Understandingofthemethod and itsprinciples
    (this is whyweareheretoday)
    Customeravailable during theproject
    Culture for opencommunication
    Self-discipline and honesty
  • ScrumPrerequisites
    Understandingofthemethod and itsprinciples
    (this is whyweareheretoday)
    Customeravailable during theproject
    Culture for opencommunication
    Self-discipline and honesty
    Remember – it is the Team and not theindividualdeveloperthat is responsible for delivering!
  • ScrumAdvantages
    Team is focused on frequently delivering value to the business
  • ScrumAdvantages
    Team is focused on frequently delivering value to the business
    DailyScrum makes all problems visible
  • ScrumAdvantages
    Team is focused on frequently delivering value to the business
    DailyScrum makes all problems visible
    Customer Collaboration makes for betterRequirements and Change Management
  • ScrumAdvantages
    Team is focused on frequently delivering value to the business
    DailyScrum makes all problems visible
    Customer Collaboration makes for betterRequirements and Change Management
    Administration and documentation kept to a minimum
  • ScrumAdvantages
    Team is focused on frequently delivering value to the business
    DailyScrum makes all problems visible
    Customer Collaboration makes for betterRequirements and Change Management
    Administration and documentation kept to a minimum
    Possibility to combine Scrum with other methodics
  • ScrumAdvantages
    Scrumgivesdevelopersbettercontrol over theirownsituation, making the team motivated
  • ScrumAdvantages
    Scrumgivesdevelopersbettercontrol over theirownsituation, making the team motivated
    A happydeveloper is a gooddeveloper!
  • DailyScrummeetingswill do
    ScrumMisunderstandings
  • DailyScrummeetingswill do
    All weneedaretheScrumartifacts
    ScrumMisunderstandings
  • DailyScrummeetingswill do
    All weneedaretheScrumartifacts
    No detailedrequirements
    ScrumMisunderstandings
  • DailyScrummeetingswill do
    All weneedaretheScrumartifacts
    No detailedrequirements
    No documentation
    ScrumMisunderstandings
  • DailyScrummeetingswill do
    All weneedaretheScrumartifacts
    No detailedrequirements
    No documentation
    No design
    ScrumMisunderstandings
  • DailyScrummeetingswill do
    All weneedaretheScrumartifacts
    No detailedrequirements
    No documentation
    No design
    No plan
    ScrumMisunderstandings
  • Coffee Break!10 minutes
  • Contents
    Part 1: Agile and Scrum
    10 min break
    Part 2: Agile Estimating and Planning
    Part 3: ScalingScrum
    10 min break
    Part 4: Exercise
  • Planning Poker
    Wikipedia: “Planning Poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development.”
  • Planning Poker
    Wikipedia: “Planning Poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development.”
    Most commonly used for estimatingeffort, butcanalso be used for estimatingvalue
  • Planning Poker
  • Planning Poker
    First, thetask is described by onewho understands it
  • Planning Poker
    First, thetask is described by onewho understands it
    Each person thenselects a card he feelsappropriate
  • Planning Poker
    First, thetask is described by onewho understands it
    Each person thenselects a card he feelsappropriate
    The cardsareshownsimultanously
  • Planning Poker
    First, thetask is described by onewho understands it
    Each person thenselects a card he feelsappropriate
    The cardsareshownsimultanously
    The person withthehighest and lowestnumberarguetheirestimate – total time no more than 5 minutes – before a newround is played
  • Planning Poker
    First, thetask is described by onewho understands it
    Each person thenselects a card he feelsappropriate
    The cardsareshownsimultanously
    The person withthehighest and lowestnumberarguetheirestimate – total time no more than 5 minutes – before a newround is played
    Ifno consensus is reachedafter 3 rounds, thetask is ”parked”
  • Planning Poker
    Baselining is done by selecting a fairlysmall and well-understoodtask and estimating it first, preferably to a lownumber, typically 2
  • Planning Poker
    Baselining is done by selecting a fairlysmall and well-understoodtask and estimating it first, preferably to a lownumber, typically 2
    The cards are numbered as they are to account for the fact that the higher an estimate is, the more uncertainty it contains
  • Planning Poker
    Baselining is done by selecting a fairlysmall and well-understoodtask and estimating it first, preferably to a lownumber, typically 2
    The cards are numbered as they are to account for the fact that the higher an estimate is, the more uncertainty it contains
    Estimates obtained through the Planning Poker process are shown to be less optimistic and more accuratethan estimates obtained through mechanical combination of individual estimates for the same tasks
  • UserStories and theProductBacklog
    A user story is a software system requirement formulated as one or two sentences in the everyday or business language of the user
    “As a customer representative, I can search for my customers by their first and last name.”
    “As a non-administrative user, I can modify my own schedules but not the schedules of other users.”
  • UserStories and theProductBacklog
    A user story is a software system requirement formulated as one or two sentences in the everyday or business language of the user
    “As a customer representative, I can search for my customers by their first and last name.”
    “As a non-administrative user, I can modify my own schedules but not the schedules of other users.”
    A User Story has value, thisvalue is visualizedwith a relative numbercalled Story Points
  • UserStories and theProductBacklog
    A user story is a software system requirement formulated as one or two sentences in the everyday or business language of the user
    “As a customer representative, I can search for my customers by their first and last name.”
    “As a non-administrative user, I can modify my own schedules but not the schedules of other users.”
    A User Story has value, thisvalue is visualizedwith a relative numbercalled Story Points
    The ProductBacklog is a prioritized list ofUserStories
  • Prioritizingthework
    UserStoriesareprioritizedaccording to thehighestValue-to-Effort (Story-Points-to-Estimate) value
  • Prioritizingthework
    UserStoriesareprioritizedaccording to thehighestValue-to-Effort (Story-Points-to-Estimate) value
  • Prioritizingthework
    UserStoriesareprioritizedaccording to thehighestValue-to-Effort (Story-Points-to-Estimate) value
    The QuickWinsgetpriority
  • Team Velocity
    Team velocity is how much product backlog effort a team can deliver in one sprint – measured in “Story points per Sprint”
    Remember, thefocus is ”howmuchvaluecanweadd to the business” andnot ”howmuchcodecanweproduce”
  • Team Velocity
    Team velocity is how much product backlog effort a team can deliver in one sprint – measured in “Story points per Sprint”
    Remember, thefocus is ”howmuchvaluecanweadd to the business” andnot ”howmuchcodecanweproduce”
    The team commits to theamoutofwork it feels it candeliver
  • Team Velocity
    Team velocity is how much product backlog effort a team can deliver in one sprint – measured in “Story points per Sprint”
    Remember, thefocus is ”howmuchvaluecanweadd to the business” andnot ”howmuchcodecanweproduce”
    The team commits to theamoutofwork it feels it candeliver
    The team quickly (2-3 sprints) achieves a fairly stable velocity (calibration)
  • DefinitionofDone (DoD)
    DoD is a checklist of valuable activities required to produce software
  • DefinitionofDone (DoD)
    DoD is a checklist of valuable activities required to produce software
    DoD is the primary reporting mechanism for team members
    a feature is either done or it is not-done
  • DefinitionofDone (DoD)
    DoD is a checklist of valuable activities required to produce software
    DoD is the primary reporting mechanism for team members
    a feature is either done or it is not-done
    DoD is informed by reality
  • DefinitionofDone (DoD)
    DoD is a checklist of valuable activities required to produce software
    DoD is the primary reporting mechanism for team members
    a feature is either done or it is not-done
    DoD is informed by reality
    DoD is not static
  • DefinitionofDone (DoD)
    DoD is a checklist of valuable activities required to produce software
    DoD is the primary reporting mechanism for team members
    a feature is either done or it is not-done
    DoD is informed by reality
    DoD is not static
    DoD is auditable
  • Questions?
  • Exercise 2: The Paper Town, part 1
    Make an estimate for a papertown to be built in nextexercise
    Specificationofthebuildingsonthenext slide (and handedout)
    Props for building: A4-paper, scissors, tape, ruler
    10 minutes
  • Exercise 2: The Paper Town, part 1specificationofbuildings
    House: 150 +/- 25 cm^2, 1 story
    1 story = 8-10 cm
    Villa: 250 +/- 25 cm^2, 1 story
    Apartement Building: 150 +/-25 cm^2, 4 stories
    Fire Departement: 300 +/- 10 cm^2, 2 storiesplus a tower, 30 +/-2 cm tall
    Police Station: 300 +/- 10 cm^2, 3 stories
    Hospital: 2 stories, 400 +/- 10 cm^2 and 250 +/- 10 cm^2
    School: 300 +/- 10 cm^2, inside a fenced area 600 +/- 10 cm^2, fence 4-6 cm tall
    General Store: 400 cm^2 +/- 25 cm, 1 story
  • Exercise 2: The Paper Town, part 1backlog
  • Exercise 2: The Paper Town, part 1prototype ofhouse
  • Exercise 2: The Paper Town, part 1ExerciseRetrospective
  • Contents
    Part 1: Agile and Scrum
    10 min break
    Part 2: Agile Estimating and Planning
    Part 3: ScalingScrum
    10 min break
    Part 4: Exercise
  • © 2009 Capgemini. All rights reserved
    Steinar Årdal & Geir Magne Trengereid
    92
    ScalingScrum(as done in the NAV Pension project)
    Daily
    Scrum
    Sprint
    SmallScrum
    Big Scrum
  • © 2009 Capgemini. All rights reserved
    Steinar Årdal & Geir Magne Trengereid
    93
    Daily
    Scrum
    Product
    Backlog
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    Xxxxxxxxxxxxxxxx
    Sprint
    Sprint
    Backlog
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    Xxxxxxxxxxxxxxxx
    New, demonstrable
    functionality at end of
    each Sprint
    4 Weeks
    The Scrumprocess
  • © 2009 Capgemini. All rights reserved
    Steinar Årdal & Geir Magne Trengereid
    94
    Scrum of Scrums
    A
    B
    C
    D
    E
    Daily ScrumOfScrums(15 min)
    • ScrumMasters & Architects(++)
    • Synchronisingthe teams
    • Focusoncommon impediments
    Product
    Backlog
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
    ScrumOfScrumsMaster
    ScrumMaster
    ScrumMaster
    ScrumMaster
    Sprint A
    Backlog
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    Sprint B
    Backlog
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    Sprint C
    Backlog
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    Sprint D
    Backlog
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    Sprint E
    Backlog
    xxxxxxxxxxxx
    xxxxxxxxxxxx
    xxxxxxxxxxxx
  • © 2009 Capgemini. All rights reserved
    Steinar Årdal & Geir Magne Trengereid
    95
    MetaScrum
    MetaScrums (15 min)
    • 3 times per week
    • ScrumMasters/TeamLeader
    • Synchronisingthe program
    • Focusoncommon impediments
    Programme
    Roadmap
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx
    MetaScrumsMaster
    Infrastructure
    Design
    Project X
    ProjectY
    ScrumOfScrumsMaster
  • Sometimessacrifices must be done…
  • Coffee Break? 10 minutes
  • Contents
    Part 1: Agile and Scrum
    10 min break
    Part 2: Agile Estimating and Planning
    Part 3: ScalingScrum
    10 min break
    Part 4: Exercise
  • Exercise 3: The Paper Town, part 2building and deploying
    Buildthebuildingsestimated in Exercise 2
    15 minutes sprint, followed by 5 minute Sprint Retrospective
    DoD:
    A building must be placedonthetown area to be ”done”
    A building must be able to support itself
    A building must be square or rectangular
    A building must have a roof
    Note that not all buildingsarerequested in all sprints!
  • Exercise 3: The Paper Town, part 2ProductBacklog Sprint 1
    • Team Commitment?
    • Whichbuildingscanyour team committ to?
  • Exercise 3: The Paper Town, part 2 Sprint 1 Retrospective
    Didyour team meetitscommitment?
    Process:
    Howdidyouorganiseyour team?
    Didyou ask theProductOwneranyquestions?
    Requirements:
    Are thereanychanges to DoD?
    Are thereanychanges to theProductBacklog?
  • Exercise 3: The Paper Town, part 2ProductBacklog Sprint 2
    • Team Commitment?
    • Whichbuildingscanyour team committ to?
  • Exercise 3: The Paper Town, part 2 Sprint 2 Retrospective
    Didyou make anyorganisationalchanges to the team?
    Didyour team meetitscommitment?
    Requirements:
    Are thereanychanges to DoD?
    Are thereanychanges to theProductBacklog?
  • Exercise 3: The Paper Town, part 2ProductBacklog Sprint 3
    A towerdoes not need to be square or rectangular
    A tower must be at least 50 cm tall, and support itself
  • Exercise 3: The Paper Town, part 2ExerciseRetrospective
  • Any Final Questions?
  • Suggested literature
  • CourseRetrospective(Bs & Cs)
  • Thankyou for yourattention