Zen of Scrum

Uploaded on

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • 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


  • 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 planThat is, while there is value in the items on the right, we value the itemson 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 RetrospectiveProduct 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 andflexibility, creativity, and productivity.” incrementally, maximizing - Scrum Guide opportunities for feedback.” - Scrum Guide
  • 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. http://www.flickr.com/photos/calypso/2767592937/Planning and Estimation
  • 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 StoriesStory XYZ 123As a ...I want to ...So that I can ... 5 points
  • 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. 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 4xestimation 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 35 2 1
  • 17. Story Points Stories Epics0 1 2 3 5 8 13 20 40 100
  • 18. Story Points0x8≠0
  • 19. Story PointsXS 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
  • 22. http://www.flickr.com/photos/john_scone/493915787/The Sprint
  • 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. Sprint Planning 1 hrs 2 hrsStory 1 123 4 hrs 4 hrs 5 points 1 hrs 8 hrs
  • 25. Product Backlog GroomingAgenda 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 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. 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. 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. 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. 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. 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. 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. 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. Sprint Burndown ChartHours Days
  • 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. Sprint RetrospectiveAgenda 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 PlanningAgenda Participants Goal for the release  Product Owner Identify features  Stakeholders Rough estimates  Scrum Master Create a release plan  Developers
  • 40. Release PlanningFixed Date Fixed Scope Can Have X weeks Might Have Won’t Have
  • 41. Release Burndown ChartStory Points Sprints
  • 42. Release Burndown Bar Chart Team Progress Completed stories Re-estimationsStory 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 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. http://www.flickr.com/photos/28481088@N00/2957770391/Scaling Scrum
  • 45. Scrum of Scrums
  • 46. Scaling Scrum Synchronize sprints between teams  Do integration at sprint boundaries Coordinate work  Lookahead planning Complexity increases
  • 47. http://www.flickr.com/photos/darkroses/2357927668/Distributed Scrum
  • 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. Distributed Daily Stand-Up Meetings Working Hours ATeam Working Hours B Time
  • 50. http://www.flickr.com/photos/droetker0912/5542920908/Additional Stuff
  • 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!