This document provides an overview of Agile and Scrum methodologies. It discusses why Agile approaches became popular, describing challenges with traditional waterfall methods. Key aspects of Scrum are outlined, including roles like Product Owner and Scrum Master, ceremonies like sprint planning and daily standups, and artifacts like product and sprint backlogs. Benefits of Scrum like adaptability, visibility and increased productivity are highlighted. The document aims to introduce readers to Scrum processes and terminology at a high level.

1. Close to Agile-Scrum introduction Wu Gang iSAP, HPIT GADSC

2. Before start Have you touched Agile / Scrum before? What do you want to learn from this session ?

3. AGENDA Why Agile What is Agile Agile Value Agile Principle Scrum How Scrum Scrum process

4. Agile

5. Why Agile

6. Agile is popular

7. IT realities IT project delivered late 90% Aberdeen IT project delivered over budget 50% Gartner IT project that fail to meet objectives 50% Gartner IT project cancelled prior to completion 30% Aberdeen

8. Situation for tradition software Dev 35% project complete on-time within budget 31% project cancelled 64% feature rarely never used

9. Complexity Can you understand enough in the beginning?

10. Losing information 2 3 4 5 1 8 9 10 6 7 6. This is document 1. Promise Made by Sales 7. This is Installation Package 2. Requirement Metioned by Customer 8. This is Cost 3. Requirement Understanded by Project Manager 9. This is Support 4. Design given by Designer 10. This is What Really Want by Customer 5. Coding performed by programer

11. What is project success Cover scope On time (before dead line) Under budget

12. Definition of success has changed Functionality 83% of respondents believe that meeting actual needs of stakeholders is more important that building the system to specific action Quality 82% believe that delivering high quality is more important that delivering on time and on budget. Money 70% believe that providing the best ROI is more important that delivering under budget Schedule 58% believe that delivering when the system is ready to be shipped is more important that delivering on schedule Source: software development project success survey, Scott Ambler , 2008

13. Agile is moving into mainstream

14. Waterfall VS. Agile

15. Waterfall vs. agile - cont Manage Change

17. Benefit of using agile Delivers faster time to market Increases productivity Reduces cost Easily adapts to changing requirements and priorities Lowers cost of change Provides better visibility into project progress Reduces risk Maximizes ROI Reduces waste Encourages higher quality and simpler code Delivers business value early and often Increases team morale

18. Survey for scrum project 88% increase productivity 93% increase quality 83% increase stakeholder satisfaction 49% reduce cost Agile Methodologies: Survey Results, by Shine Technologies, 2003

19. Agile

20. What is Agile Ag-ile (adj.) Characterized by quickness, lightness and ease of movement; nimble Agile is simple (not easy) Agile is about doing the important things first and taking small steps It’s about people, values, principles, and practices that foster team communication and learning and improving as you go along to regularly deliver customer value through working software

21. Agile manifesto 1 3 2 4 Individuals and interactionsover processes and tools Customer collaborationover contract negotiation Working softwareover comprehensive documentation Responding to changeover following a plan

22. Agile Principles Satisfy the Customer Welcome Change Deliver Frequently Work as a Team Motivate People Communicate Face-to-Face Measure Working Software Maintain Constant Pace Excel at Quality Keep it Simple Evolve Designs Reflect Regularly

24. What is Scrum

25. Scrum

26. Scrum

27. Scrum 100 words Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time It allows us to rapidly and repeatedly inspect actual working software ( every two weeks to one month). The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

28. What Scrum look like

29. Scrum characteristics Self-organizing teams Product progresses in a series of time boxed Sprints Requirements are captured as items in a list of Product backlog No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects One of the Agile processes.

30. How Scrum

32. Scrum Master

33. Team

34. Sprint

35. Sprint planning

36. Sprint review

37. Sprint retrospective

38. Daily scrum meeting

39. Product backlog

40. Sprint backlog

43. Scrum Master

44. Team

45. Sprint

46. Sprint planning

47. Sprint review

48. Sprint retrospective

49. Daily scrum meeting

50. Product backlog

51. Sprint backlog

53. Team What he is Typically 5-9 people Cross functional Full Time Self-Organized What he can do Define tasks Estimate effort Develop product Ensure quality Evolve processes Deliver Success

54. Scrum master What he is Servant leader Team protector Troubleshooter Scrum guide What he can do Remove impediments Prevent interruptions Facilitate the team Support the process Manage management Ensure Success

55. Pigs and Chickens Product Owner Scrum Master Team Members Users Managers Marketing

57. Scrum Master

58. Team

59. Sprint

60. Sprint planning

61. Sprint review

62. Sprint retrospective

63. Daily scrum meeting

64. Product backlog

65. Sprint backlog

67. Valued

68. EstimatedProduct Backlog

69. Product backlog

70. User stories As a <user> I want <functionality>( so that <benefit> ) As a guest, I want to cancel a reservation, As a hotel employee, I can run RevPAR reports so that I can help to improve the quality of service

71. Typical fields

72. Principle of create User story Independent Negotiable Valued Estimable Small Testable

74. Small (1-16hours)

75. Team EstimatedSprint Backlog

76. Sprint BackLog 8 4 8 16 12 4 10 8 16 11 8 16 12 8 8 8 8 8 4 Add error logging 8 Tasks Mon Tues Wed Thur Fri Code the user interface Code the middle tier Test the middle tier Write online help Write the foo class

77. Task Board Visible Editable Update Daily Own By team

78. Product BackLog VS Sprint Backlog Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4) As a vacation planner, I want to see photos of the hotels.

79. Burndown charts Effort Left Date

80. Brundown Charts Update daily, usually during the daily stand-up Represent the amount of work remaining Different approaches to create burndown charts Estimated remaining time Track done

81. Tasks Mon Tues Wed Thur Fri 4 8 12 7 10 16 11 16 8 Burndown charts Code the user interface 8 Code the middle tier 16 Test the middle tier 8 50 Write online help 12 40 30 Hours 20 10 0 Mon Tue Wed Thu Fri

82. Burndown charts Possible over commitment Possible Under commitment Commitment achieved. Keep this velocity for next Sprint

84. Scrum Master

85. Team

86. Sprint

87. Sprint planning

88. Sprint review

89. Sprint retrospective

90. Daily scrum meeting

91. Product backlog

92. Sprint backlog

94. Sprint Sprint 2-4 weeks Scrum projects make progress in a series of “sprints” Analogous to Extreme Programming iterations Typical duration is 2–4 weeks or a calendar month at most A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint

95. Sprint Change Plan sprint durations around how long you can commit to keeping change out of the sprint

96. Sprint Planning Sprint backlog Team selects items from the product backlog they can commit to completing Sprint backlog is created Tasks are identified and each is estimated (1-16 hours) Collaboratively, not done alone by the Scrum Master High-level design is considered

98. Select sprint goal

99. Decide how to achieve sprint goal (design)

100. Create sprint backlog (tasks) from product backlog items (user stories / features)

101. Estimate sprint backlog in hoursSprint Planning Sprint goal Sprint planning meeting Team capacity Product backlog Business conditions Current product Techno-logy

102. Daily Scrum meeting Parameters Daily 15-minutes Stand-up Not for problem solving Whole world is invited Only team members, ScrumMaster, product owner, can talk Helps avoid other unnecessary meetings

103. Daily scrum meeting Only the team talks Not to Scrum Master No problem solving Max 15 minutes Standing up 1 2 3 What have you done yesterday? What will be done today? Is anything in your way?

104. Sprint review Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule No slides Whole team participates Invite the world

105. Sprint retrospective Periodically take a look at what is and is not working Typically 15–30 minutes Done after every sprint Whole team participates ScrumMaster Product owner Team Possibly customers and others

106. Sprint retrospective

107. Review

109. Scrum Master

110. Team

111. Sprint

112. Sprint planning

113. Sprint review

114. Sprint retrospective

115. Daily scrum meeting

116. Product backlog

117. Sprint backlog

119. There’s no silver bullets

120. Thank you