Scrum overview
Download as PPT, PDF•1 like•1,062 views
Scrum is a process for developing products quickly through self-organizing, cross-functional teams that prioritize customer features in time-boxed iterations. It contrasts with traditional waterfall methods by emphasizing iterative development, flexibility to change, and real-time collaboration among team members. Key practices include sprint planning, daily stand-ups, and retrospectives to ensure continuous improvement and stakeholder engagement.
Scrum overview
- 1. Scrum Overview Rob Bastian The definition of insanity is doing the same thing over and over and expecting different results. Benjamin Franklin
- 2. Scrum Key Takeaways Self directed, self organizing cross functional team Planning driven by customer prioritization Time boxed iterations Daily stand up meeting Demo at end of each iteration
- 3. What is Scrum anyway? Scrum is a process for developing products such as software and quickly getting the products to the customer. Iterative and incremental development method Emphasis on empirical process management rather than defined process Empirical means “ Originating in or based on observations and modifications ” CMM Level/3 and ISO 9001 compliant
- 4. Royce: The Waterfall Model In 1970, Dr. Winston Royce published “Managing the development of large Software Systems” System Req. Software Req. Analysis Program Design Coding Testing “ I believe in this concept, but The implementation described above is Risky and invites failure ”
- 5. Royce: The Waterfall Model On the next page showed the following: System Req. Software Req. Analysis Program Design Coding Testing “ Hopefully, the iterative interaction between The various phases is confined to Successive steps
- 6. Waterfall is a powerful attractor For Management It is a “defined process” – thus “feels right” It gives the illusion of control Of time Of people Of money Allows for “hands off” management For Developers It’s just “following a recipe” Left alone for long periods of time
- 7. Why is Waterfall less than optimal? Built on the assumption that we can figure out what we need to do ahead of time and then plan accordingly Building software is about solving problems and not all problems can be anticipated so the ability to constantly change course in the face of issues is critical “ No no no, I'm going to leave them alone and not actually witness them dying, I'm just gonna assume it all went to plan. What? “ – Dr. Evil
- 8. Why is Waterfall less than optimal? One study showed that typical requirements specifications are 15% complete and only 7% correct and that it was not cost effective to complete or correct them Evidence/data indicates that more detailed up-front requirements not only does NOT help much in preventing requirements change, but in fact makes requirements change MORE likely (because many of the details you tried to "guess" up-front we're wrong and have to be changed)
- 9. Why is Waterfall less than optimal? We can’t really know what we need until we see a little of what we have Customers change their minds Developers see new possibilities New function often require new designs Building an architecture up front assumes: You know what you really need You don’t overbuild it People will follow it It anticipates all needs and doesn’t need to change – that is architectures are often built to be filled out, not to evolve as needs change
- 10. Why is Waterfall less than optimal? Features aren’t prioritized Why prioritize features if they’ll all be implemented? Developers potentially work on least important features first Most important features may not get done Testing always gets impacted The reality is the delivery dates are hard to move Engineering tasks that take longer than anticipated will “steal” time from the QA team “ Stealing” from QA costs more later…
- 11. How is Scrum different? Planning and Prioritization Iterations, Increments and Features Refactoring and Emergence Self-organized and Cross Functional Collaboration
- 12. How is Scrum different? Planning and Prioritization. Planning Scrum team meets with stakeholders at the beginning of an iteration to plan what work will be taken on during the iteration Scrum team meets every day for 15 minutes to plan daily work Prioritization Stakeholders prioritize features so we know we’re working on most important features first
- 13. How is Scrum different? Iterations, Increments and Features Feature driven Scrum teams focus on building vertical slices of an application feature by feature Three/four levels of “done” Time boxed Team works in iterations Team decides how much work will “fit” into the iteration At the end of an iteration a increment of working functionality is delivered At the end of an iteration the team demonstrates what it built to stakeholders
- 14. How is Scrum different? Refactoring and Emergence. No big up front design Architecture/infrastructure emerges as features are completed and refactoring is done Refactoring MUST be done as features are implemented or you’ll be toast You Aren’t Going to Need It (YAGNI) It’s better to let the features drive the architecture as they are developed than to attempt to build it all up front
- 15. How is Scrum different – Self organized and cross functional collaboration Self Organization Team should decide how best to accomplish the goal of the iteration Team Swarm Entire team can “swarm” on an issue or task until it’s complete – e.g. writing acceptance tests Cross Functional Anyone should be able to contribute to any task (within reason)
- 16. Scrum Process Sprint Planning Meeting Sprint Daily 15 minute meeting (Scrum meeting) Sprint Review Retrospective
- 17. Sprint Planning Meeting Part I – Establish a Sprint Goal Product owner prioritizes work for team for the next Sprint (iteration) and works with team to determine how much work will “fit” into next Sprint Work is defined in the Product Backlog document that contains all known and outstanding enhancements and non-critical bugs Product owner is ensured that only highest priority work is being done Part II – Task Breakdown and Estimation Team breaks down product backlog items into work or tasks no more than 16 hours in length Tasks include QA tasks, unit and rtests, platform processes like design documentations and code reviews If tasks cannot be identified because not enough investigation is done then investigation tasks are tracked to determine approach
- 19. Sprint Fixed length iteration. Recommendation is 30 calendar days Team and Customer agree on what work can be completed during Sprint and define a goal Team self organizes to do work Team conforms to standards and procedures Team only works on tasks directly related to completing sprint goals
- 20. The Daily Scrum Meeting Attended by developers, testers, analysts, customers and Scrum master Normally standing meeting to encourage brevity. 15-20 minutes No other discussion beyond the 3 questions What did you do since we last met? What are you going to work on next? Is there anything impeding your progress? Scrum master tracks and resolves issues What does “done” mean
- 21. Example Sprint Backlog and Burn Down Chart
- 22. Sprint Review Meeting Empirical observation by management and stakeholders on progress of the project The scrum teams shows accomplishments during the sprint Demo Informal All stake holders are invited Project assessed against sprint goals Maintains trust by not hiding undone work Functionality
- 23. A Metric Leading to Agility Running Tested Features The desired software is broken down into named features (requirements, stories) which are part of what it means to deliver the desired system. For each named feature, there are one or more automated acceptance tests which, when they work, will show that the feature in question is implemented. The RTF metric shows, at every moment in the project, how many features are passing all their acceptance tests.
- 24. A Metric Leading to Agility (cont)
- 25. Retrospective Scrum team and customer attends Process improvement at the end of every sprint What went well, what can be improved What does management need from us Team devices solution to most vexing problems
- 26. Appendix
- 27. Scrum Flow
- 28. How we normally deliver functionality What we know to start Functionality / Problem solved Effort expended (design, coding, etc)
- 29. Tracer Bullets A single piece of functionality is developed within the overall system structure and the development environment. This functionality works from the user interface, through all intermediate levels to the persistent data stores and back. This “tracer bullet” demonstrates that the development environment and operation environment work, allowing the team and users to refine their aim in future iterations 1 . 1 Andy Hunt and Dave Thomas (The Pragmatic Programmer)
- 30. Up Front Requirements Evidence indicates that no matter how detailed you try to flesh-out the requirements "up front", it still wont prevent more details from being discovered, and that you couldn’t have known them earlier before delving into design/implementation details
- 31. Ready, Fire, Aim, Aim, Aim… *Ready, Fire, Aim * Ready…Aim… Aim… Aim… Aim… Fire… Aim, aim, aim, aim…