Lecture #4 introduction to scrum in project management
- 1. Scrum Guide
- 2. Scrum Theory Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Three pillars uphold every implementation of empirical process control: 1. transparency, 2. inspection, and 3. adaptation Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document: Sprint Planning Daily Scrum Sprint Review Sprint Retrospective
- 3. Scrum Framework Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Scrum is: Lightweight Simple to understand Difficult to master
- 5. The Scrum Team The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional.
- 9. SCRUM Roles, Events, and Artifacts
- 10. Scrum Roles
- 14. Product Owner Represents the product's stakeholders and the voice of the customer Define the features of the product Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results. Ensuring the Development Team understands items in the Product Backlog to the level needed.
- 15. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 15 Product or Project Release Iteration Story The Planning Onion can grow to include product portfolios and business strategy Product Portfolio Business Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 15
- 16. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 16 The product owner role comes from the specific Agile process Scrum It’s called “the snowman model” (see the snowman?)
- 17. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 17 Product Owner Responsibilities Organize the backlog into incremental releases Specify objective acceptance criteria for stories •Communicate Business Goals, Customer Goals, End User Goals •Coordinate involvement of SMEs, users, and business stakeholders •Coordinate with other product owners to insure coherence of product and releases Create and maintain the product backlog Participate daily Be available to answer questions and clarify details on user stories Verify stories are done based on acceptance criteria Evaluate product at end of Sprint and add or remove stories from backlog as necessary
- 18. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 18 Product Owner Team Developmen Team Design and Coded Features Pass Back and Forth Between Tracks implement iteration 1 features •gather user input for iteration 3 features •design iteration 2 features •support iteration 1 development implement iteration 2 features fix iteration 1 bugs if any •gather user input for iteration 4 features •design iteration 3 features •support iteration 2 development •validate iteration 1 features implement iteration 3 features fix iteration 2 bugs if any •gather user input for iteration 5 features •design iteration 4 features •support iteration 3 development •validate iteration 2 features •planning •data gathering •design for iteration 1 features – high technical requirements, low user requirements •development environment setup •architectural “spikes” Sprint 0 Sprint 1 Sprint 2 Sprint 3 f e a t u r e d e s i g n c o d e d f e a t u r e s tim e f e a t u r e d e s i g n + b u g s f o u n d i n u s a b i l i t y t e s t i n g support dev support dev
- 20. Scrum Master Represents management to the project. Responsible for enacting Scrum values and practices. Removes impediments . Ensure that the team is fully functional and productive. Enable close cooperation across all roles and functions. Shield the team from external interferences.
- 21. Scrum Master Helping the product owner maintain the product backlog in a way that ensures the needed work is well understood so the team can continually make forward progress. Helping the team to determine the definition of done for the product, with input from key stakeholders. Coaching the team, within the Scrum principles, in order to deliver high- quality features for its product. Educating key stakeholders in the product on Scrum principles.
- 22. Development Team Typically 5-9 people Cross-functional: Programmers, testers, user experience designers, etc. Members should be full-time. Is self-organizing team. They called delivery team and its members just team members. Build the product increments (analysis, design, development, testing, technical writing, etc.x
- 23. Scrum Events
- 24. The Sprint The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. During the Sprint: No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
- 25. The Sprint Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product. Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase
- 26. Cancelling a Sprint A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master. A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re- estimated and put back on the Product Backlog
- 27. Sprint Planning at the beginning of a sprint, the scrum team holds a sprint planning event to plan for The work to be performed in the Sprint . This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming Sprint? How will the work needed to deliver the Increment be achieved?
- 28. Sprint Planning: What can be done this Sprint? The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment
- 29. Sprint Planning : How will the chosen work get done? During the first half, the whole scrum team (development team, scrum master, and product owner) selects the product backlog items they believe could be completed in that sprint During the second half, the development team identifies the detailed work (tasks) required to complete those product backlog items; resulting in a confirmed sprint backlog As the detailed work is elaborated, some product backlog items may be split or put back into the product backlog if the team no longer believes they can complete the required work in a single sprint
- 30. Daily Scrum The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain: 1. What did I do yesterday that helped the Development Team meet the Sprint Goal? 2. What will I do today to help the Development Team meet the Sprint Goal? 3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
- 31. Sprint Review A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. This is a four-hour time-boxed meeting for one-month Sprints. The Sprint Review includes the following elements:
- 32. Sprint Review
- 33. Sprint Retrospective The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. Is a three-hour time-boxed meeting for one-month Sprints The purpose of the Sprint Retrospective is to: Inspect how the last Sprint went with regards to people, relationships, process, and tools; Identify and order the major items that went well and potential improvements; and, Create a plan for implementing improvements to the way the Scrum Team does its work.
- 34. Scrum Artifacts
- 35. Product Backlog The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. A Product Backlog is never complete. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value. Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.
- 36. Sprint Backlog The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.
- 39. Scrum Graph provided by VersionOne. http://www.versionone.com/state_of_agile_development_survey/11/ 39
- 40. Scrum Resources Online Recommendations • The Scrum Guide by Scrum.org. (Online Book) o http://www.scrum.org/Portals/0/Documents/Scrum% 20Guides/Scrum_Guide.pdf • Scrum Alliance o http://www.scrumalliance.org • Jeff Sutherland o http://scrum.jeffsutherland.com • Mountain Goat Software - Mike Cohn's Blog o http://www.mountaingoatsoftware.com/blog 40