Scrum Process

13,340 views
12,884 views

Published on

Published in: Technology, Business
3 Comments
9 Likes
Statistics
Notes
No Downloads
Views
Total views
13,340
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
479
Comments
3
Likes
9
Embeds 0
No embeds

No notes for slide

Scrum Process

  1. 1. The Scrum Process John A. Lewis Chief Software Architect Unicon, Inc. 29 July 2010 © Copyright Unicon, Inc., 2010. Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/us/
  2. 2. Method vs. Methodology <ul><li>Admittedly, this is a pet peeve: </li><ul><li>Method : A means or manner of procedure, especially a regular and systematic way of accomplishing something
  3. 3. Methodology : A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods; The study or theoretical analysis of such working methods </li></ul><li>Scrum (and other such things) are methods – not methodologies </li></ul>
  4. 4. Agile Software Development
  5. 5. Manifesto for Agile Software Development <ul><li>We are uncovering better ways of developing software by doing it and helping others do it.
  6. 6. Through this work we have come to value: </li><ul><li>Individuals and interactions over processes and tools
  7. 7. Working software over comprehensive documentation
  8. 8. Customer collaboration over contract negotiation
  9. 9. Responding to change over following a plan </li></ul><li>That is, while there is value in the items on the right, we value the items on the left more . </li></ul>From the “Manifesto for Agile Software Development” See http://agilemanifesto.org/
  10. 10. Principles of Agile Development <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  11. 11. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  12. 12. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  13. 13. Business people and developers must work together daily throughout the project.
  14. 14. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  15. 15. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul>
  16. 16. Principles of Agile Development (cont) <ul><li>Working software is the primary measure of progress.
  17. 17. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  18. 18. Continuous attention to technical excellence and good design enhances agility.
  19. 19. Simplicity—the art of maximizing the amount of work not done—is essential.
  20. 20. The best architectures, requirements, and designs emerge from self-organizing teams.
  21. 21. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
  22. 22. Nature of A Complete Method <ul><li>There are two critical aspects of a software development method: </li><ul><li>Process : How the project is conducted and coordinated. Provides for project management and control mechanisms. Not specific to software development.
  23. 23. Practice : How the developers perform software development. A set of practices and conventions that all developers follow in order to collaborative effectively and produce high-quality results quickly. </li></ul></ul>
  24. 24. The Scrum Process
  25. 25. Scrum Process <ul><li>Scrum is an Agile Process for running Software Development Projects.
  26. 26. Uses an Empirical Process control model instead of a Defined Process control model.
  27. 27. This means it depends on “Inspect and Adapt” cycles, instead of phases, hand-offs, sign-offs, and blame.
  28. 28. These cycles require regular inspections of the process, and constant adaptations to steer the direction of the process based on those inspections.
  29. 29. Scrum is made up of two cycles: </li><ul><li>The Monthly Scrum Sprint (“the Sprint”)
  30. 30. The Daily Scrum Meeting (“the Scrum”) </li></ul><li>All activity takes place within these two cycles. </li></ul>
  31. 31. Scrum Process Flow
  32. 32. The Scrum Sprint <ul><li>Monthly cycle that results in a potentially shippable increment of the software product.
  33. 33. During this period the team is empowered to do whatever it takes to meet their goal.
  34. 34. Sprint length actually variable. Anything from 1-6 weeks is fine – adapt to pace of project.
  35. 35. Must develop an initial Product Backlog before beginning the first Sprint. </li></ul>
  36. 36. Product Backlog <ul><li>Prioritized list of all features and changes that have yet to be made to the system.
  37. 37. High-level and loosely defined. Doable by one person in one Sprint.
  38. 38. Scrum Master is the owner and the ultimate arbiter of what's on the list and the priorities.
  39. 39. Before the first Sprint, the Scrum Master and the Scrum Team produce an initial Backlog. </li></ul>
  40. 40. Sprint Planning Meeting <ul><li>Initial step for each Sprint.
  41. 41. Attended by the Scrum Master, the Scrum Team, and any other parties that want to see how the next Sprint will likely go.
  42. 42. 1 st half of the meeting (~ 4 hours): </li><ul><li>Scrum Team and the Scrum Master select items from Product Backlog that can be implemented in the next monthly Sprint.
  43. 43. Scrum Team and the Scrum Master agree on a Sprint Goal. </li></ul><li>2 nd half of the meeting (~ 12-20 hours): </li><ul><li>The Scrum Team creates the Sprint Backlog. </li></ul></ul>
  44. 44. Sprint Goal <ul><li>Each Sprint has a specific and stated goal.
  45. 45. Simple statement of what the Scrum Team will accomplish during the Sprint. Not more that a few sentences.
  46. 46. Capture the spirit of where the product will be at the end of the Sprint.
  47. 47. Used to measure the general level of success during the Sprint Review. </li></ul>
  48. 48. Sprint Backlog <ul><li>Scrum Team takes the Product Backlog items for the Sprint and distills them into items for the Sprint Backlog.
  49. 49. Sprint Backlog items are lower-level and much more defined – measured in hours, not days – estimated from 1 - 16 hours or so.
  50. 50. Preferably managed in an Issue Tracking system (e.g. JIRA).
  51. 51. During a Sprint, if entirely new tasks are discovered, they can be added to the Sprint Backlog.
  52. 52. If a new task is not related to the Sprint Goal, then it is tossed back into the Product Backlog, to be prioritized by the Scrum Master. </li></ul>
  53. 53. The Daily Scrum Meeting <ul><li>Within the Sprint, the Scrum Team gathers in the same place at the same time each work day.
  54. 54. Provides daily chance to “Inspect and Adapt”.
  55. 55. The Scrum Master asks each person, in turn: </li><ul><li>&quot;What have you done since the last Scrum meeting?&quot;
  56. 56. &quot;What do you plan to do before the next Scrum meeting?&quot;
  57. 57. &quot;What impediments are in your way?&quot; </li></ul><li>After the Daily Scrum, the team gets to work and the Scrum Master sets about removing impediments. </li></ul>
  58. 58. The Scrum Team <ul><li>The Team consists of 5-9 people who will develop the product.
  59. 59. During each Sprint, the Scrum Team has two requirements: </li><ul><li>Attend the Daily Scrum.
  60. 60. Update the Sprint Backlog. </li></ul><li>The important metric on the Sprint Backlog is the estimated work remaining, not the work already done.
  61. 61. A task that had 3 hours remaining on Monday may have 5 hours remaining on Tuesday and 10 hours remaining on Wednesday, even though the developer has worked on it solid for 2 days. This is normal! </li></ul>
  62. 62. Burndown Chart <ul><li>Need fully estimated Spring Backlog updated daily
  63. 63. Scrum Master can produce daily Burndown Chart
  64. 64. Shows trend towards timely completion of the Sprint Backlog </li></ul>
  65. 65. Pigs and Chickens <ul><li>A not-so-funny joke: </li></ul>A chicken and a pig decide to start a restaurant. The pig says, &quot;What should we call it?“ The chicken says, &quot;How about 'Ham & Eggs'?“ The pig says, &quot;No thanks. I'd be committed, but you'd just be involved!&quot; <ul><li>People on the Scrum Team are Pigs (committed) – everyone else is a Chicken (involved).
  66. 66. At the Daily Scrum, only Pigs can talk. Chickens can come to the meeting to observe and learn, but they cannot: </li><ul><li>Talk.
  67. 67. Make funny faces.
  68. 68. Whisper.
  69. 69. Take notes loudly.
  70. 70. Communicate in any way. </li></ul><li>If they do, they must leave.
  71. 71. If they persist, they will be banned from the meeting. </li></ul>
  72. 72. Sprint Review <ul><li>When the Sprint is complete, the Sprint Team conducts a demonstration of what was completed. No more than 2 hours of preparation are allowed.
  73. 73. This should be purely a functioning demo – no use of PowerPoint (unless you are developing PowerPoint itself!) or other slides / mockups.
  74. 74. The entire Sprint Team and the Scrum Master should attend. Others who are interested in seeing the results of the Sprint may also attend. Customer attendance is highly desirable.
  75. 75. Purpose is to solicit feedback. Observations and comments will commonly become items on the Product Backlog. </li></ul>
  76. 76. Complexity Points <ul><li>Abstract estimations for Product Backlog
  77. 77. Also sometime called “Story Points” since its an estimate for each User Story
  78. 78. Assign points to each item to indicate relative complexity
  79. 79. Use Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21
  80. 80. Add up all the complexity points for the Sprint gives you a measure of the scope </li></ul>
  81. 81. Planning Poker <ul><li>Process for team Complexity Point estimates
  82. 82. Use set of playing cards with the various CP numbers – give each team member a set
  83. 83. Discuss the Backlog item and then each pick a card and lay down at the same time
  84. 84. Look for consensus or discuss further for more clarity and then repeat estimate
  85. 85. Avoids “groupthink” by having everyone give their own estimate simultaneously, rather than in sequence </li></ul>
  86. 86. Scrum Team Velocity <ul><li>After each Sprint, measure the number of Complexity Points the team completed
  87. 87. Averaging these over several Sprints will give the Team Velocity
  88. 88. This allows for fairly accurate predictions of the rate at which the team can complete the remaining Product Backlog items that have CP estimates </li></ul>
  89. 89. Adopting the Scrum Process <ul><li>The Scrum Process can be rolled out quickly with new projects via some simple training (i.e. these slides + supporting material).
  90. 90. The Scrum Master and Tech Leads will need additional training and coaching as the project progresses.
  91. 91. Good to have at least one or two people on the team who have done Scrum before, or have access to people who have done it before to ask questions. </li></ul>
  92. 92. Resources <ul><li>Website: http://www.scrumalliance.org/
  93. 93. Book: &quot;Agile Software Development With Scrum&quot; by Ken Schwaber
  94. 94. Blog: Implementing Scrum by Mike Vizdos
  95. 95. Mailing List: Scrum Development Yahoo! Group
  96. 96. Planning Poker: http://www.planningpoker.com/ </li></ul>
  97. 97. Questions & Answers John A. Lewis Chief Software Architect Unicon, Inc. [email_address] www.unicon.net

×