Introduction to scrum
0 likes208 views
This document provides an introduction to SCRUM, an agile framework for developing software. It discusses the core concepts of SCRUM including roles, events, artifacts, and values. The three main roles are the Product Owner, Development Team, and Scrum Master. Key events in the SCRUM process are the Sprint Planning Meeting, Daily Scrum, Sprint Review, and Sprint Retrospective. Main artifacts include the Product Backlog and Sprint Backlog. The document also covers user stories, estimation techniques, and how a typical SCRUM sprint cycle works.
Introduction to scrum
- 1. Introduction to SCRUM Md. Mojammel Haque CSP, CSD, CSPO, CSM- Scrum Allience
- 6. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
- 8. #1: Customer satisfaction by rapid delivery of useful software
- 9. #2: Welcome changing requirements, even late in development
- 10. #3: Working software is delivered frequently
- 11. #4: Close, daily cooperation between business people and developers
- 12. #5: Projects are built around motivated individuals, who should be trusted
- 13. #6: Face-to-face conversation is the best form of communication (co-location)
- 14. #7: Working software is the principal measure of progress
- 15. #8: Sustainable development, able to maintain a constant pace
- 16. #9: Continuous attention to technical excellence and good design
- 17. #10: Simplicity—the art of maximizing the amount of work not done—is essential
- 19. #12: Regular adaptation to changing circumstance
- 21. What is SCRUM? Scrum is an Agile framework for developing, delivering and sustaining complex products. Scrum is Iterative & Incremental method Scrum is Lightweight Simple to understand Difficult to master
- 22. What SCRUM Follows Empirical Process Control theory i.e. knowledge comes from experience & makes decision based on what is known.
- 23. Values of SCRUM Commitment Courage Focus Openness Respect When they are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum roles, events, and artifacts.
- 24. History of SCRUM Scrum formalized in 1990 by Jeff Sutherland & Ken Schwaber
- 25. What is Scrum being used for? Commercial software In-house development Fixed-price projects Financial applications ISO 9001-certified applications 24x7 systems with 99.999% uptime requirements Video game development US FDA-approved software for X-Rays, MRIs Satellite-control software Websites, Mobile phones Network switching applications Large database applications CMMi organizations Multi-location development Non-software projects
- 26. Scrum has been used by- Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce Intuit Nielsen Media
- 27. Disadvantages of SCRUM SCRUM is hard! Makes all dysfunction visible Scrum doesn’t fix anything: the team has to do it Feels like things are worse at the beginning Bad product will be delivered sooner and doomed projects will fail faster Some teams and organizations are not right or ready for it Team willingness, capabilities Management Risk of turnover during adoption Some people will refuse to stay on a Scrum team Some people will refuse to stay if Scrum is abandoned Partial adoption may be worse than none at all
- 28. Foundations of SCRUM The heart of SCRUM is “Sprint”- a time boxed which are not extended There are 02 artifacts, 03 roles, 04 events are closely related with the Sprint.
- 29. SCRUM Roles- The Product Owner
- 30. SCRUM Roles- The Product Owner Responsible for the overall project vision and goals Responsible for managing project ROI vs. risk Responsible for managing Product Backlog Clearly express the product backlog items Ordering the items based on their priorities Ensures backlog items visible, transparent and clear to all Ensures development team understands the items of backlog to the level as needed. Participates actively in Sprint Planning and Sprint Review meetings, and is available to team throughout the Sprint Determines release plan and communicates it to upper management and the customer
- 31. SCRUM Roles- The Development Team
- 32. SCRUM Roles- The Development Team Responsible for delivering a potentially releasable increments of “Done” product at the end of the sprint Self Organizing Team manages itself to achieve the Sprint commitment Cross Functional All the skills as a team necessary to create a product Increment Team takes on tasks based on skills, not just official “role” Size should be of 6 persons, + or -3 Can be shared with other teams (but better when not) Can change between Sprints (but better when they don’t) Can be distributed (but better when co-located)
- 33. SCRUM Roles- The Scrum Master
- 34. SCRUM Roles- The Scrum Master Servant-leader for the team. Does everything to help the team achieve success including- Serving the Team Protecting the Team Guiding the team’s use of SCRUM
- 35. Scrum Master- Serving the team Takes action to help remove impediments to the team’s effectiveness. Facilitates the team’s group interactions, to help the team achieve its full potential Coaches the team, to help them improve their practices and effectiveness
- 36. Scrum Master- Protects the Team Protects the team from anything that threatens its effectiveness, such as outside interference or disruption Deal with uncomfortable issues, both inside and outside the team
- 37. Guiding the team’s use of Scrum Teaches Scrum to the team and organization Ensures that all standard Scrum rules and practices are followed Organizes all Scrum-related practices
- 38. Difference between Boss & SM
- 40. What happens to the “Project Manager” in SCRUM?
- 41. Transforming “Project Manager” to ….. There is no such role is scrum where we can have a project manager. We need to transform our traditional project managers to Scrum Master (Highly risk involved as the intention of managing the team will be there) Product Owner Team Member (Hard to adjust as a member of the team)
- 42. Starting SCRUM
- 43. Product Backlog
- 44. Product Backlog Product Owner lists items in descending order of priority (highest priority item is listed first, next- highest is second, etc.) Size estimates are rough estimates (can either be arbitrary “points”, or “ideal days”)
- 45. Product Backlog List of everything that could ever be of value to the business for the team to produce Ranked in order of priority Priority is a function of business value versus risk Product Owner can make any changes they want before the start of a Sprint Planning Meeting Items added, changed, removed, reordered How much documentation is up to the team and Product Owner to decide The farther down the list, the bigger and less defined the items become ~2 Sprints worth are defined in detail
- 46. User Stories User Stories are a good approach for writing Product Backlog Items User Stories are a short, plain-language description of the functionality, in terms of the customer benefit and need
- 47. Good Format of User Stories As a ….. I want ….. So that …..
- 48. Examples of well formatted user stories “As a customer, I can place an item on my wish- list, so that I can decide later whether or not I want to buy it” “As a frequent flyer member, I can see the number of miles I have earned in my frequent flyer account, so that I can decide whether to redeem them for a ticket” “As a new user, I can set up a profile so that potential employers can find out more about my skills and qualifications”
- 49. Epics Larger user stories are referred as Epic. Epics generally take more than one or two sprints to develop and test. They are usually broad in scope, short on details, and will commonly need to be split into multiple, smaller stories before the team can work on them.
- 50. Themes A theme is a collection of related user stories A user Story can belong to one or more themes. An Epic can be sliced into several stories. One way to remember that all of these sliced stories is related is to say that they belong to a particular theme
- 51. Tasks An user story can be further sliced further tasks like- UI Design Database Design Server side Business logic implement Client side Business logic implement etc. Tasks are generally contains by “Sprint Backlog”
- 52. INVEST in Good Stories and SMART Tasks Stories should be- I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable Tasks should be- S – Specific M – Measurable A – Achievable R – Relevant T – Time-boxed
- 53. How to Set the Story point (Est. Size of Story) Planning Poker First of all team should agree a story (from backlog item) as “baseline” or “benchmark” and give it a size e.g.- 5 Size = Effort x Complexity x Uncertainty
- 54. How to Set the Story point (Est. Size of Story) Planning Poker Team will given / create cards with following values-
- 55. How to Set the Story point (Est. Size of Story) Planning Poker 1. Product owner will pick a story from backlog and ask the team to estimate it’s size in respect of already estimated story 2. Each person will decide their cards at the same time. In this case no one will share his/her number with other. This is very secret. 3. Everyone will show their card at once when Scrum Master will says “1-2-3-show” 4. If estimates vary significantly then high and low estimators will explain briefly why 5. Repeat step 2-4 until estimates stop converging 6. Decided estimates are the size of Backlog item 7. Move to next backlog item
- 56. How to Set the Story point (Est. Size of Story) Planning Poker
- 57. Estimated Size / Story Point of Product Backlog
- 59. Sprint Planning Meeting Takes place before the start of every Sprint Team decides how much Product Backlog it will commit to complete by the end of the Sprint, and comes up with a plan and list of tasks for how to achieve it What’s a good commitment? Clearly understood by all Shared among the team Achievable without sacrificing quality Achievable without sacrificing sustainable pace Attended by Team, Product Owner, Scrum Master, Stakeholders May require 2 hours for each week of Sprint duration 2 week Sprint = 4 hours, 4 week Sprint = 8 hours
- 60. Sprint Planning Meeting (Cont.) Sprint Planning Meeting further divided into two parts- Sprint Pre-Planning Meeting Sprint Planning Meeting Sprint Pre-Planning Meeting Team understands the details of what the Product Owner has prioritized on the Product Backlog Team Set the Size of each Story Sprint Planning Meeting Team decides how much productive time it has available during the Sprint Team decides how many Product Backlog items it can commit to complete during the Sprint
- 61. Sprint Pre-Planning Meeting Should take place 2-3 days before the actual sprint planning meeting Team must understand the prioritized items by product owner and ask for clarification if required Provide rough estimation for new items Calculate team’s available days, hours etc. The Dev Team, Product Owner, and ScrumMaster look ahead to upcoming Product Backlog Items (or User Stories) coming in the next 2-3 Sprints They split larger items into smaller slices – ideally, small enough that 1-2 people could completely finish them in 3-4 days (“1-2-3-4”) They start to get a more detailed understanding of the requirements for these upcoming Product Backlog Items No fixed format, timing, or timebox: try a 2-3 hour session for Dev Team, Product Owner and ScrumMaster
- 62. Sprint Cycle- 2 Weeks Sprint
- 63. Sprint Cycle- 4 Weeks Sprint
- 64. Available Time during Sprint *Net holidays & other days out of the office
- 65. Available Hours Per day Different members can have different responsibilities. Based on those differences approximate available hour per day calculation-
- 66. Available Hours Per day
- 67. Available Hours Per day
- 68. Available Hours Per day
- 69. Available Hours Per day
- 70. Definition of Done (DoD) Definition of Done (DoD) has been described as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality. The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete. Until this list is satisfied, a product Increment is not done. During the Sprint Planning meeting, the Scrum Team develops or reconfirms its DoD, which enables the Development Team to know how much work to select for a given Sprint. The Definition of Done is not changed during a Sprint, but should change periodically between Sprints to reflect improvements the Development Team has made in its processes and capabilities to deliver software.
- 71. Demo of DoD
- 72. Demo of DoD
- 73. Demo of DoD
- 74. Creating Sprint Backlog Team will break an Story into Multiple Tasks Estimate the effort/time of each task Here Volunteer means the member who will complete the task.
- 75. Sprint Planning Ends when… Team’s available time is mostly committed Good idea to go through and make sure there’s full agreement on the commitment After the meeting, Scrum Master turns the task list into the Sprint Backlog
- 76. The Sprint is Begin
- 77. Daily SCRUM
- 78. Daily SCRUM Purpose of Daily Scrum Meeting Keep team coordinated and up-to-date with each other Surface impediments daily How it works Every weekday Whole team attends Team chooses a time that works for everyone Product Owner can attend, but doesn’t speak Everyone stands in a circle, facing each other (not facing the SM) Lasts 15 minutes or less Everyone reports 3 things only to each other What was I able to accomplish since last meeting What will I try to accomplish by next meeting What are my blocks / problems / difficulties No discussion or conversation until meeting ends
- 79. Daily SCRUM- Not Allowed
- 80. Daily SCRUM- Perfect Standup
- 81. Update Sprint Backlog After the Daily Scrum, team members update the hours remaining on the Sprint Backlog Also moves cards on the visual task board
- 82. Update Sprint Backlog After the Daily Scrum, team members update the hours remaining on the Sprint Backlog Also moves cards on the visual task board
- 83. Update Sprint Backlog *. Column 1,2,3,4,5,6 indicates days of the sprint. *. Value of those columns i.e. 4,3,0 etc. indicates how much time remaining to complete the task.
- 84. Burn-down Chart Show the teams progress visually through a Chart.
- 85. Task Board
- 86. Task Board
- 87. Task Board
- 88. Task Board
- 89. Task Board
- 90. Task Board
- 91. Task Board
- 92. Task Board
- 93. Some important note (About Task Board) Use sticky paper on a board or use pin and paper on a soft board so that items are easy to move Can assign different color for team members, task type or themes Should be visible from a sitting position (for everyone) Item can move forward or backward Can be customized to have more than 2 columns
- 94. What about any changes during the Sprint?
- 95. No Changes During Sprint No Changes to the Deliverable Once team has committed, no changes to the deliverable If something major comes up, Product Owner can terminate the Sprint and start new one Details and clarifications will emerge during Sprint, but no new work or substantially changed work Difference between “change” and “clarification” “If there’s any doubt, then it’s a change
- 96. What if a change is required? Do not allow any changes in current sprint Move the item for next sprint Break the sprint and start a new sprint with modified backlog Product owner should be responsible for breaking the sprint or removing items from the sprint
- 97. The End of Sprint
- 98. Sprint Review
- 99. Sprint Review Purpose of the Sprint Review Demo what the team has built Make visible whether the team completed what they set out to Generate feedback, which the Product Owner can incorporate in the Product Backlog Attended by Team, Product Owner, ScrumMaster, functional managers, and any other stakeholders A demo of what’s been built, not a presentation about what’s been built No Power-points allowed! Usually 4 hours for 4 weeks sprint, 2 hours for 2 weeks, 1 hour for 1 week sprint
- 100. Sprint Retrospective
- 101. Sprint Retrospective Occurs after Sprint Review and prior to next sprint planning 03 hours meeting for one hour sprint, 1.5 hours for two weeks sprint, 45 minutes for 1 week sprint Product Owner, Team and Scrum Master will attended Generally Scrum Master Facilitate the Meeting but if possible call Neutral Person to Facilitate the Meeting Discuss about What’s working What’s could better Things try to next sprint
- 102. Why Retrospective Matter? Accelerates the Visibility Accelerates action to improve
- 103. Good approach of Retrospective Create 03 large list on a whiteboard What’s working What’s could work better Things to try in the next Sprint Allow each person to add one or more items to the 3 lists If people agree with something already on the lists then put a tick mark next to that Select a subset from “Things to Try” list and try in the next sprint. (Scrum Master responsible for tracking this)
- 104. Good approach of Retrospective
- 106. Any Question?
- 107. Thanks