a 3-hour Scrum Awareness course

1. ScrumAwareness 2.0.1 Ådne Brunborg <date>

2. Who am I? Ådne Brunborg Senior Consultant at Capgemini since march 2005 Over 11 yearsexperience as… Developer Architect Team Leader

3. Audienceexpectations?

4. 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

5. Contents Part 1: Agile and Scrum 10 min break Part 2: Agile Estimating and Planning Part 3: ScalingScrum 10 min break Part 4: Exercise

6. Contents Part 1: Agile and Scrum 10 min break Part 2: Agile Estimating and Planning Part 3: ScalingScrum 10 min break Part 4: Exercise

7. 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

8. Scrum

9. 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 )

10. Scrum Wikipedia: ”Scrum is an iterative incremental process of software development commonly used with agile software development.”

11. 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”

12. 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!

13. Scrum in 100 words (or less) Scrum is an Agile process focuses on delivering the highest business value in the shortest time

14. 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

15. 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

16. 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

17. 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

18. ScrumOverview

19. ScrumOverview ScrumArtifacts ScrumProcess ScrumRoles

20. The Artifacts ProductBacklog a prioritized list of high level requirements

21. The Artifacts ProductBacklog a prioritized list of high level requirements Sprint Backlog a list of tasks to be completed during the sprint

22. 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”

23. 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

24. ScrumBoardexample

25. Live Demo: BurndownChart

26. 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?

27. 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!

28. 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

29. Questions?

30. 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

32. The PigRoles The Team developers, designers, testers… responsible for deliveringtheproduct

33. The PigRoles The Team developers, designers, testers… responsible for deliveringtheproduct The Scrum Master responsible for facilitatingtheScrumprocess

34. 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").

35. The ChickenRoles End Users For whomthe software is built

36. The ChickenRoles End Users For whomthe software is built Stakeholders (customers, vendors ) The business side

37. The ChickenRoles End Users For whomthe software is built Stakeholders (customers, vendors ) The business side Management The organisation side

38. Questions?

39. ScrumPrerequisites Understandingofthemethod and itsprinciples (this is whyweareheretoday)

40. ScrumPrerequisites Understandingofthemethod and itsprinciples (this is whyweareheretoday) Customeravailable during theproject

41. ScrumPrerequisites Understandingofthemethod and itsprinciples (this is whyweareheretoday) Customeravailable during theproject Culture for opencommunication

42. ScrumPrerequisites Understandingofthemethod and itsprinciples (this is whyweareheretoday) Customeravailable during theproject Culture for opencommunication Self-discipline and honesty

43. 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!

44. ScrumAdvantages Team is focused on frequently delivering value to the business

45. ScrumAdvantages Team is focused on frequently delivering value to the business DailyScrum makes all problems visible

46. ScrumAdvantages Team is focused on frequently delivering value to the business DailyScrum makes all problems visible Customer Collaboration makes for betterRequirements and Change Management

47. 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

48. 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

49. ScrumAdvantages Scrumgivesdevelopersbettercontrol over theirownsituation, making the team motivated

50. ScrumAdvantages Scrumgivesdevelopersbettercontrol over theirownsituation, making the team motivated A happydeveloper is a gooddeveloper!

51. DailyScrummeetingswill do ScrumMisunderstandings

52. DailyScrummeetingswill do All weneedaretheScrumartifacts ScrumMisunderstandings

53. DailyScrummeetingswill do All weneedaretheScrumartifacts No detailedrequirements ScrumMisunderstandings

54. DailyScrummeetingswill do All weneedaretheScrumartifacts No detailedrequirements No documentation ScrumMisunderstandings

55. DailyScrummeetingswill do All weneedaretheScrumartifacts No detailedrequirements No documentation No design ScrumMisunderstandings

56. DailyScrummeetingswill do All weneedaretheScrumartifacts No detailedrequirements No documentation No design No plan ScrumMisunderstandings

57. Coffee Break!10 minutes

58. Contents Part 1: Agile and Scrum 10 min break Part 2: Agile Estimating and Planning Part 3: ScalingScrum 10 min break Part 4: Exercise

59. 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.”

60. 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

61. Planning Poker

62. Planning Poker First, thetask is described by onewho understands it

63. Planning Poker First, thetask is described by onewho understands it Each person thenselects a card he feelsappropriate

64. Planning Poker First, thetask is described by onewho understands it Each person thenselects a card he feelsappropriate The cardsareshownsimultanously

65. 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

66. 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”

67. Planning Poker Baselining is done by selecting a fairlysmall and well-understoodtask and estimating it first, preferably to a lownumber, typically 2

68. 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

69. 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

70. 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.”

71. 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

72. 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

73. Prioritizingthework UserStoriesareprioritizedaccording to thehighestValue-to-Effort (Story-Points-to-Estimate) value

74. Prioritizingthework UserStoriesareprioritizedaccording to thehighestValue-to-Effort (Story-Points-to-Estimate) value

75. Prioritizingthework UserStoriesareprioritizedaccording to thehighestValue-to-Effort (Story-Points-to-Estimate) value The QuickWinsgetpriority

76. 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”

77. 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

78. 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)

79. DefinitionofDone (DoD) DoD is a checklist of valuable activities required to produce software

80. 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

81. 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

82. 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

83. 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

84. Questions?

85. 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

86. 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

87. Exercise 2: The Paper Town, part 1backlog

88. Exercise 2: The Paper Town, part 1prototype ofhouse

89. Exercise 2: The Paper Town, part 1ExerciseRetrospective

90. Contents Part 1: Agile and Scrum 10 min break Part 2: Agile Estimating and Planning Part 3: ScalingScrum 10 min break Part 4: Exercise

91. © 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

92. © 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

94. Synchronisingthe teams

95. Focusoncommon impedimentsProduct 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

97. ScrumMasters/TeamLeader

98. Synchronisingthe program

99. Focusoncommon impedimentsProgramme Roadmap xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx MetaScrumsMaster Infrastructure Design Project X ProjectY ScrumOfScrumsMaster

100. Sometimessacrifices must be done…

101. Coffee Break? 10 minutes

102. Contents Part 1: Agile and Scrum 10 min break Part 2: Agile Estimating and Planning Part 3: ScalingScrum 10 min break Part 4: Exercise

103. 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!

108. 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

109. Exercise 3: The Paper Town, part 2ExerciseRetrospective

110. Any Final Questions?

111. Suggested literature

112. CourseRetrospective(Bs & Cs)

113. Thankyou for yourattention