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
Zen of Scrum
Zen of Scrum
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.
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
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
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
http://www.flickr.com/photos/calypso/2767592937/Planning and Estimation
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
User StoriesStory XYZ 123As a ...I want to ...So that I can ... 5 points
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
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
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
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
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.
Product Backlog GroomingAgenda Participants Update the product Product Owner backlog Scrum Master Refine and split top stories Developers Estimate stories
Sprint Rules No changes affecting the Sprint goal No changes to team Scope may be discussed, re-negotiated and clarified as knowledge is gained
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?
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
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.
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
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
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
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
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
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
Sprint RetrospectiveAgenda Participants Inspect last sprint Scrum Master People and relationships Developers Process and tools Identify potential improvements Plan for implementing improvements
Release Burndown Bar Chart Team Progress Completed stories Re-estimationsStory points Sprints Workload changes Added features Removed features
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
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. !
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. !
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. !
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. !
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
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