Published on

Introduction to scrum from Railscamp Melbourne 2009

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Scrum Breccan McLeod-Lundy (Certified ScrumMaster)
  2. 2. Roles <ul><li>Scrum Master
  3. 3. Product Owner
  4. 4. Team member </li></ul>
  5. 5. Product Owner <ul><li>Decides what features are needed
  6. 6. Prioritizes features
  7. 7. Explains features to the team
  8. 8. There can be only one </li></ul>
  9. 9. Team <ul><li>Works as a multi-talented group
  10. 10. Commits to tasks
  11. 11. Self-manages </li></ul>
  12. 12. Scrum Master <ul><li>Acts as a facilitator
  13. 13. Maintains the scrum process
  14. 14. Assists with removing problems for the teams
  15. 15. Is not an interface between the team and product owner </li></ul>
  16. 16. Timeboxing <ul><li>Time in Scrum works on the basis of timeboxes
  17. 17. Meetings of all types should be strictly time boxed
  18. 18. Releases and sprints are also timeboxed to dates. </li></ul>
  19. 19. Product Backlog <ul><li>A list of the features that could be included in the product.
  20. 20. In priority order
  21. 21. Can be reordered by the product owner at will. </li></ul>
  22. 22. Release Planning <ul><li>Initial discussion between the team and product owner trading information.
  23. 23. Lays out goals for the project and identifies when a viable release could occur.
  24. 24. Longest meeting in the entire project. Still wouldn't normally be more than 3 hours.
  25. 25. Includes deciding 'done definition' and initial estimates on tasks. </li></ul>
  26. 26. Done <ul><li>The done definition defines when a task becomes considered done.
  27. 27. Must include everything that is required for something for something to be done.
  28. 28. Would normally include testing requirements, documentation etc.
  29. 29. Some requirements can be separate tasks instead of being in the done definition. </li></ul>
  30. 30. Initial Estimates <ul><li>The team gives ballpark estimates on the tasks in the product backlog
  31. 31. Allows the product owner to fix any glaring problems in the cost benefit of how they've prioritized tasks.
  32. 32. A number of techniques are available to assist the estimation process. </li></ul>
  33. 33. Sprint Planning <ul><li>The team selects tasks from the top of the product backlog to complete in the sprint.
  34. 34. Product owner can clarify details of features or requirements.
  35. 35. Based on an amount that they believe they can take through to done in the given time period.
  36. 36. The team commits to this work as the scope for the current sprint and moves it to the sprint backlog. </li></ul>
  37. 37. Sprint Backlog <ul><li>Cannot be changed
  38. 38. Tracks the tasks that are part of the sprint
  39. 39. Stages should suit the project. We mostly use: </li><ul><ul><li>Not started, in progress, in test, to be verified by client and done </li></ul></ul><li>Put somewhere visible so that the teams knows what's happening. </li></ul>
  40. 40. Daily Scrums <ul><li>Short(1-2 minutes per team member) daily meetings.
  41. 41. Only team members speak
  42. 42. Consists of each team member saying: what they did in the last day, what they'll do in the next day and if anything is blocking them.
  43. 43. Can spawn followups where necessary(blocks, common tasks etc.) </li></ul>
  44. 44. Sprint Review <ul><li>Team shows off things that are done.
  45. 45. Review status of product backlog with done tasks completed.
  46. 46. Collaborative discussion regarding what could likely come next on the product backlog with the product owner. </li></ul>
  47. 47. Retrospective <ul><li>Team members and scrum master only.
  48. 48. Team reviews its development process to see what they think went well and what went badly in the last sprint.
  49. 49. Suggests and adopts changes they would like to make to the approach in the next sprint to improve the development process. </li></ul>
  50. 50. Product and Sprint Burndowns <ul><li>Track the completion of tasks and stories.
  51. 51. Allow for an easy view of velocity in a project. So problems can be caught.
  52. 52. Knowing velocity makes it easier for the team to judge the number of tasks to pick up in future sprints. </li></ul>