Zen of Scrum
Download as PPTX, PDF•13 likes•4,370 views
The document discusses key principles of Scrum, including valuing individuals and interactions over processes, working software over documentation, and responding to change over following a plan. It describes Scrum goals of delivering working software frequently through iterations, favoring customer collaboration, and responding to changing requirements. Scrum uses self-organizing cross-functional teams, daily stand-ups, sprints, and retrospectives to deliver working increments iteratively.
Zen of Scrum
- 1. Zen of Scrum
- 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 plan That is, while there is value in the items on the right, we value the items on the left more.
- 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. Scrum Values Courage Commitment Respect Openness Focus
- 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 Retrospective Product backlog Increment
- 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 and flexibility, creativity, and productivity.” incrementally, maximizing - Scrum Guide opportunities for feedback.” - Scrum Guide
- 7. Definition of Done It is crucial to have the same definition of done in the Scrum team, between teams, across the organization, and when talking 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
- 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. User Stories Story XYZ 123 As a ... I want to ... So that I can ... 5 points
- 11. User Stories INVEST 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. 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. Cone of Uncertainty 4x estimation accuracy 2x 1x 0.5x 0.25x Project evolvement
- 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. Estimating with Story Points
- 16. Estimating with Story Points 2 3 5 2 1
- 17. Story Points Stories Epics 0 1 2 3 5 8 13 20 40 100
- 19. Story Points XS S M L XL
- 20. Poker Planning
- 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
- 23. Sprint Planning Agenda Participants Select user stories Product Owner Identify and estimate Scrum Master technical tasks Developers Come up with sprint goal Two parts: (a) Selecting stories and (b) identifying tasks. The PO and stakeholders only need to participate in the first half, but must still be available during the second half.
- 24. Sprint Planning 1 hrs 2 hrs Story 1 123 4 hrs 4 hrs 5 points 1 hrs 8 hrs
- 25. Product Backlog Grooming Agenda Participants Update the product Product Owner backlog Scrum Master Refine and split top stories Developers Estimate stories
- 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. Sprint Emergency Procedure Three 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. Sprint Length Size 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. Daily Stand-Up Meeting Agenda 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 three questions, keep any discussions outside the meeting. Instead, meet immediately after the Daily Scrum for re- planning and further discussions.
- 30. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement a Story 1 123 working API 5 points BURNDOWN CHART Story 2 127 1 points UNPLANNED Story 3 213 8 points NEXT Story 4 129 5 points 5 points 3 points
- 31. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement a Story 1 123 MN working API 5 points BURNDOWN CHART SA Story 2 127 1 points UNPLANNED Story 3 213 PL 8 points NEXT Story 4 129 5 points 5 points 3 points
- 32. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement a Story 1 123 MN SA working API 5 points BURNDOWN CHART SA Story 2 127 1 points UNPLANNED Story 3 213 PL 8 points NEXT PL Story 4 129 5 points 5 points 3 points
- 33. Sprint Backlog STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL Implement a Story 1 123 MN SA working API 5 points BURNDOWN CHART SA MN Story 2 127 PL 1 points UNPLANNED Story 3 213 PL SA 8 points NEXT MN PL Story 4 129 5 points 5 points 3 points
- 34. Sprint Backlog STORY TO DO TESTS COMPLETE IN PROGRESS ”DONE” HOURS (2) Story 1 123 SA 32 5 points MN SA Story 2 127 1 points 8 Story 3 213 PL 8 points 48 PL
- 35. Sprint Burndown Chart Hours Days
- 36. Sprint Review Agenda 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. Sprint Retrospective Agenda Participants Inspect last sprint Scrum Master People and relationships Developers Process and tools Identify potential improvements Plan for implementing improvements
- 38. http://www.flickr.com/photos/acediscovery/3030548744/ Release Planning
- 39. Release Planning Agenda Participants Goal for the release Product Owner Identify features Stakeholders Rough estimates Scrum Master Create a release plan Developers
- 40. Release Planning Fixed Date Fixed Scope Can Have X weeks Might Have Won’t Have
- 41. Release Burndown Chart Story Points Sprints
- 42. Release Burndown Bar Chart Team Progress Completed stories Re-estimations Story points Sprints Workload changes Added features Removed features
- 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 10 Theme, 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
- 45. Scrum of Scrums
- 46. Scaling Scrum Synchronize sprints between teams Do integration at sprint boundaries Coordinate work Lookahead planning Complexity increases
- 48. Distributed Scrum To 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. Distributed Daily Stand-Up Meetings Working Hours A Team Working Hours B Time
- 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. 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. 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. 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. 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. Further Reading Devoted Developer – www.devoteddeveloper.com The Scrum Guide - www.scrum.org ”Agile Estimating and Planning”, Mike Cohn, 2005 Addison-Wesley - www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning User Story Primer - trailridgeconsulting.com/files/user-story-primer.pdf Scrum Alliance - www.scrumalliance.org/ How to Split a User Story - rslawrence.wpengine.com/wp- content/uploads/2012/01/Story-Splitting-Flowchart.pdf
- 57. Time’s up!
Editor's Notes
- #8: Three levels of DoD: Task DoD (when all tasks are done, the story is done), Story DoD (when all the stories are done, the sprint is done) and Release DoD