Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Zen of Scrum


Published on

Introduction to Scrum: a product development framework based on agile principles.

Published in: Business, Technology, Spiritual

Zen of Scrum

  1. 1. Zen of Scrum
  2. 2. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a planThat is, while there is value in the items on the right, we value the itemson the left more.
  3. 3. Scrum Goals Deliver working (“potentially Work shippable”) software frequently by developing functioning software in each iteration Transparency Favor customer collaboration by encouraging customer involvement Inspect throughout the project Respond to changing requirements, even late in Adapt development, by not planning ahead in too much detail Avoid procrastination, or ”student’s “Scrum employs an syndrome”, by working in small iterative, incremental approach to increments optimize predictability and control risk.” - Scrum Guide
  4. 4. Scrum Values Courage  Commitment Respect  Openness Focus
  5. 5. Scrum Distilled scrum team iterations events Daily Scrum Daily Scrum 24 hours Stand-Up Master Sprint Sprint Planning 2-4 weeks Team Sprint backlog Sprint Review Product Release Sprint Owner 2-6 months RetrospectiveProduct backlog Increment
  6. 6. Scrum Team Product Scrum Team Owner Master (Developers)  Responsible for Product  Ensure Scrum is  Deliver potentially Backlog (PBL) understood and enacted releasable increment of  Ensure developers  Scrum coach “Done” product at the understand PBL items  Removing impediments end of each Sprint  Maximize ROI  Facilitate meetings  Self-organizing  Cross-functional “Scrum Teams deliver products“…designed to optimize iteratively andflexibility, creativity, and productivity.” incrementally, maximizing - Scrum Guide opportunities for feedback.” - Scrum Guide
  7. 7. Definition of DoneIt is crucial to have the same definition of done in the Scrumteam, between teams, across the organization, and whentalking to other stakeholders and customers. Everybody must understand what “done” means Helps during estimation Ensures transparency Helps to avoid technical debt “As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.” - Scrum Guide
  8. 8. and Estimation
  9. 9. Product Backlog Ordered list of everything that might be needed in the product Single source of requirements Dynamic “The Product Backlog is often ordered by value, risk, priority, and necessity. Top- ordered Product Backlog items drive immediate development activities. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value.” - Scrum Guide
  10. 10. User StoriesStory XYZ 123As a ...I want to ...So that I can ... 5 points
  11. 11. User StoriesINVEST in the user stories Independent – avoid dependencies on other stories Negotiable – stories are not a contract Valuable – show the value to customers/stakeholders Estimable – sufficient detail needs to be present Sized right – small enough to complete in one sprint Testable – Acceptance criteria should be apparent in story
  12. 12. Estimation Key Points It’s easier to estimate relatively than absolutely It’s difficult impossible to accurately estimate calendar time Firmly establish estimates by team commitment Separate the task of estimating size and duration Only re-estimate relative changes
  13. 13. Cone of Uncertainty 4xestimation accuracy 2x 1x 0.5x 0.25x Project evolvement
  14. 14. Story Points vs Ideal Days Ideal days are easily confused with calendar time, especially when communicating outside the team My ideal day is not your ideal day Ideal days always have a relationship to calendar days. If the project takes twice the ideal days in calendar time to finish, it does not mean the team is 50% efficient If everything takes longer (or shorter, even though longer is much more common :-P) you do not have to re-estimate; this is more intuitive using story points
  15. 15. Estimating with Story Points
  16. 16. Estimating with Story Points 2 35 2 1
  17. 17. Story Points Stories Epics0 1 2 3 5 8 13 20 40 100
  18. 18. Story Points0x8≠0
  19. 19. Story PointsXS S M L XL
  20. 20. Poker Planning
  21. 21. Story Splitting Sometimes stories are too big for one sprint Story Splitting Patterns  Boundaries: Operational, data, interfaces  Remove cross-cutting concerns: Logging, Exception handling, ...  Functional and non-functional aspects  Business value Anti-Patterns When in doubt, do a spike solution
  22. 22. Sprint
  23. 23. Sprint PlanningAgenda Participants Select user stories  Product Owner Identify and estimate  Scrum Master technical tasks  Developers Come up with sprint goalTwo parts: (a) Selecting stories and (b) identifying tasks. ThePO and stakeholders only need to participate in the firsthalf, but must still be available during the second half.
  24. 24. Sprint Planning 1 hrs 2 hrsStory 1 123 4 hrs 4 hrs 5 points 1 hrs 8 hrs
  25. 25. Product Backlog GroomingAgenda Participants Update the product  Product Owner backlog  Scrum Master Refine and split top stories  Developers Estimate stories
  26. 26. Sprint Rules No changes affecting the Sprint goal No changes to team Scope may be discussed, re-negotiated and clarified as knowledge is gained
  27. 27. Sprint Emergency ProcedureThree questions to ask before canceling a sprint: 1. Can anything be changed in the way work is done? 2. Can anyone outside the team help? 3. Can something be dropped from the sprint backlog?
  28. 28. Sprint LengthSize matters. Shorter is better! Feedback more often Stable velocity quicker React to changes faster Learn processes faster ”If it wasn’t for the last minute, nothing would ever get done.” - a lot more last minutes
  29. 29. Daily Stand-Up MeetingAgenda Participants What has been accomplished  Scrum Master since the last meeting?  Developers What will be done before the  Passive: Other interested next meeting? parties - only listen! What obstacles are in the way?Same time and place every day. Only answer the threequestions, keep any discussions outside the meeting.Instead, meet immediately after the Daily Scrum for re-planning and further discussions.
  30. 30. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement aStory 1 123 working API 5 points BURNDOWN CHARTStory 2 127 1 points UNPLANNEDStory 3 213 8 points NEXT Story 4 129 5 points 5 points 3 points
  31. 31. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement aStory 1 123 MN working API 5 points BURNDOWN CHART SAStory 2 127 1 points UNPLANNEDStory 3 213 PL 8 points NEXT Story 4 129 5 points 5 points 3 points
  32. 32. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement aStory 1 123 MN SA working API 5 points BURNDOWN CHART SAStory 2 127 1 points UNPLANNEDStory 3 213 PL 8 points NEXT PL Story 4 129 5 points 5 points 3 points
  33. 33. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement aStory 1 123 MN SA working API 5 points BURNDOWN CHART SA MNStory 2 127 PL 1 points UNPLANNEDStory 3 213 PL SA 8 points NEXT MN PL Story 4 129 5 points 5 points 3 points
  34. 34. Sprint Backlog STORY TO DO TESTS COMPLETE IN PROGRESS ”DONE” HOURS (2)Story 1 123 SA 32 5 points  MN SAStory 2 127 1 points 8Story 3 213 PL 8 points  48 PL
  35. 35. Sprint Burndown ChartHours Days
  36. 36. Sprint ReviewAgenda Participants What has been  Product Owner done, what has not been  Scrum Master done  Developers What went well, any problems  Stakeholders Product backlog What to do next
  37. 37. Sprint RetrospectiveAgenda Participants Inspect last sprint  Scrum Master  People and relationships  Developers  Process and tools Identify potential improvements Plan for implementing improvements
  38. 38. Release Planning
  39. 39. Release PlanningAgenda Participants Goal for the release  Product Owner Identify features  Stakeholders Rough estimates  Scrum Master Create a release plan  Developers
  40. 40. Release PlanningFixed Date Fixed Scope Can Have X weeks Might Have Won’t Have
  41. 41. Release Burndown ChartStory Points Sprints
  42. 42. Release Burndown Bar Chart Team Progress Completed stories Re-estimationsStory points Sprints Workload changes Added features Removed features
  43. 43. Parking Lot Diagram Theme, subsystem, product Theme, epic, fe Theme, epic, fe Theme, epic, fe ature set ature set ature set (8) (8) (8) 50% 50% 0% Sprint 8 Sprint 3 Sprint 10Theme, subsystem, product Theme, subsystem, product Theme, epic, fe Theme, epic, fe Theme, epic, fe Theme, epic, fe ature set ature set ature set ature set (8) (4) (8) (4) 50% 25% 0% 0% Sprint 8 Sprint 3 Sprint 12 Sprint 12
  44. 44. Scrum
  45. 45. Scrum of Scrums
  46. 46. Scaling Scrum Synchronize sprints between teams  Do integration at sprint boundaries Coordinate work  Lookahead planning Complexity increases
  47. 47. Scrum
  48. 48. Distributed ScrumTo be successful... Shared vision and goal  Tools for distributed Personal relationships collaboration  Virtual Scrum boards  Kick-off meeting  Video conferencing  Workshops  Screen sharing Same standards and values  Estimation  Definition of Done
  49. 49. Distributed Daily Stand-Up Meetings Working Hours ATeam Working Hours B Time
  50. 50. Stuff
  51. 51. Scrum Misconceptions” Scrum says documentation isn’t important. Documentation is important, but working software is valued more. !” People need to be ”cross- Teams need to be cross- functional”. That sounds both inefficient and unrealistic. functional, not people. Nonetheless, it is always a good idea not to rely on one person. Spread the knowledge. !
  52. 52. Scrum Misconceptions” We can’t estimate in size, I need to know when we can Using story points you can still deliver. estimate when the project will be completed. The important difference is that duration is derived from size. !” It’s not possible to mix Maybe you will not reach Scrum’s Scrum and our traditional project model (read: waterfall) full potential, but you can benefit from agile methods nontheless. !
  53. 53. Scrum Misconceptions” We’re working on a fixed price contract, so we can’t use Let the project manager act as Scrum. product owner, and use Scrum inside your organization. !” Scrum does not work with Good point. Co-located teams are distributed teams. always best, but it is possible to use Scrum in a distributed organization as well. !
  54. 54. Scrum Misconceptions” When you split stories you create dependencies, but you Stories should independently bring should INVEST in the user stories? (Stories should be independent) value to the product. They can still have logical dependencies on other stories. Remember: the product backlog is ordered. !
  55. 55. Supporting Practices XP practices  Sustainable pace  Pair programming  Collective code ownership  Coding standards  Test Driven Development (TDD)  Refactoring  Continuous Integration (CI)  Spikes Meeting Techniques  Preparation  Time boxing Pragmatic Programming
  56. 56. Further Reading Devoted Developer – The Scrum Guide - ”Agile Estimating and Planning”, Mike Cohn, 2005 Addison-Wesley - User Story Primer - Scrum Alliance - How to Split a User Story - content/uploads/2012/01/Story-Splitting-Flowchart.pdf
  57. 57. Time’s up!