Scrum Guide Notes
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 8
| Download | |
| Open PDF In Browser | View PDF |
Scrum Guide Notes Vasileios Papadopoulos Agile Software Development Note As a framework, Scrum will never provide you with exact processes or show you exactly how to deal with problems. Instead, it provides a set of rules and relies on the team to find the best possible solution - A different approach to the software development process - Focuses on the clean delivery of individual pieces or parts of the software and not on the entire application - Requirements & solutions evolve through the collaborative effort of teams and their customers and/or end users - Encourages early delivery and continuous improvement - The term Agile was popularized in 2001 when the Agile Manifesto was published Concept - Small team of people that is highly flexible and adaptive - Employ an iterative, incremental approach to optimize predictability and control risk - Make decisions based on empirical process control theory, or empiricism Agile Manifesto Empiricism - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan Definition of Scrum Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. What is a framework? A framework is a system of rules, ideas, or beliefs that is used to plan or decide something. Knowledge comes from experience and making decisions on what is known. Scrum Consists of - Roles Events Artifacts Rules Scrum Optimizes - Flexibility - Creativity - Productivity Three Pillars of Scrum - Transparency Make significant aspects of the process visible to those responsible for the outcome Page 1 of 8 - Inspection Frequently inspect the progress towards a goal to detect undesirable variances - Adaption Adjust the process as soon as possible to minimize further deviation Self-organization Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functionality Scrum Values - Commitment People personally commit to achieving the goals of the Scrum Team - Courage The Scrum Team members have courage to do the right thing and work on tough problems - Focus Everyone focuses on the work of the Sprint and the goals of the Scrum Team - Openness The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work - Respect Scrum Team members respect each other to be capable, independent people The Scrum Team Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The Product Owner - Responsible for maximizing the value of the product resulting from work of the Development Team - One person, not a committee - The only person responsible for managing the Product Backlog. They have the final say on its content and ordering and everyone must respect their decisions Note The Product Owner may have the Development Team or someone else manage the Product Backlog. They, however, remain accountable - Product Owner - Development Team Product Backlog - Scrum Master Note Be careful not to confuse the Scrum Team with the Development Team. The Scrum Team contains the Development Team, along with the Product Owner and the Scrum Master Scrum Team Characteristics - Deliver products iteratively and incrementally - Self-organizing - Cross-functional - A prioritized list of desired product functionality - Provides a shared understanding of what is needed in the product and in which order Product Owner - Product Backlog - Clearly express Product Backlog Items - Order the items in the Product Backlog to best achieve goals and missions - Optimize the value of work the Development Team performs - Ensure that the Product Backlog is visible, transparent, clear to all and shows what the Scrum Team will work on next Page 2 of 8 - Ensure that the Development Team understands the Product Backlog to the level needed The Development Team - Consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint - Only members of the Development Team create the Increment - Size: 3 to 9 members Note The Scrum Guide suggests to have a Development Team of 3 to 9 members but this is not a requirement. A Development Team can still have 15 members however, it won’t be as effective. Scrum Master - Product Owner - Ensure that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible - Find techniques for effective Product Backlog management - Help the Scrum Team understand the need for clear and concise Product Backlog Items - Ensure the Product Owner knows how to arrange the Product Backlog to maximize value - Understand product planning in an empirical environment - Understand and practice agility - Facilitate Scrum events as requested or needed Scrum Master - Development Team Development Team Characteristics - Coach the Development Team in organization and cross-functionality - Self-organizing - Cross-functional - Scrum recognizes no titles for Development Team members - Scrum recognizes no sub-teams in the Development Team - Accountability belongs to the team as a whole - Help the Development Team create high-value products self- - Remove impediments to the Development Team’s progress - Facilitate Scrum events as requested or needed - Coach the Development Team in organizational environments in which Scrum is not yet fully adopted and understood The Scrum Master - Promotes and supports Scrum - Helps everyone understand Scrum theory, practices and rules - Acts as a Servant-Leader for the Scrum Team - Helps those outside the Scrum Team understand which interactions are helpful and which aren’t Note As servant-leader the Scrum Master guides and coaches the Scrum Team. They are not allowed, however, to tell the team what to do or how to do it unless related to the Scrum framework Scrum Master - Organization - Lead and coach the organization in its Scrum adoption - Plan Scrum implementations within the organization - Help employees and stakeholders understand and enact Scrum and empirical product development - Cause change that increases the productivity of the Scrum Team - Work with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization Page 3 of 8 Scrum Events Cancelling a Sprint - The Sprint - Only the Product Owner has the authority to cancel a Sprint - The Sprint is cancelled if the Sprint Goal becomes obsolete - 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 reestimated and put back on the Product Backlog - Sprint Planning - Daily Scrum - Sprint Review - Sprint Retrospective Scrum Event Characteristics - Create regularity - Minimize the need for meetings not defined in Scrum - Time-boxed (have max duration) - Each event is an opportunity to inspect and adapt something - Failure to include any of these events results in reduced transparency Note Sprint cancellations are often traumatic to the Scrum Team and should be avoided. They also consume resources as everyone regroups in another Sprint Planning to start another Sprint. The Sprint Sprint Planning - Acts as a container for all other events - Duration: One month or less (consistent duration) - A new sprint starts immediately after the conclusion of the previous Sprint - A “Done”, potentially releasable Product Increment is created - Consists of: – – – – – Sprint Planning Daily Scrums Development Work Sprint Review Sprint Retrospective During the Sprint - No changes are made that would endanger the Sprint Goal - What can be delivered in the Increment resulting from the upcoming Sprint? - How will the work needed to deliver the Increment be achieved? - The plan is created by the collaborative work of the entire Scrum Team - Max duration: 8 hours for one-month Sprint - Attendees: All Scrum Team members Sprint Planning - Input - Product Backlog - Latest Product Increment - Projected capacity of the Development Team during the Sprint - Past Performance of the Development Team Sprint Planning - Notes - Quality goals do not decrease - Scope may be clarified and re-negotiated between the Product Owner and the Development Team as more is learned - The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team Page 4 of 8 - The Product Owner can help to clarify selected Product Backlog Items and make tradeoffs Daily Scrum - Notes - The Development Team may renegotiate selected Product Backlog Items with the Product Owner - The Scrum Master ensures that the Development Team has the meeting but the Development Team is responsible for conducting the Daily Scrum - The Development Team may invite other people to attend to provide technical or domain advice - The Scrum Master teaches the team to keep the Daily Scrum within the 15-minute timebox - Output: Sprint Backlog and Sprint Goal - The Development Team or team members often meet immediately after the Daily Scrum for related discussions Sprint Backlog - The Product Backlog Items selected for this Sprint - It is an internal meeting for the Development Team. If others are present, the Scrum Master ensures they do not disrupt the meeting - A plan for delivering them Daily Scrum - Benefits Sprint Goal - Improve communications - Eliminate other meetings - An objective that will be met within the Sprint through the implementation of the selected Product Backlog Items - Provides guidance to the Development Team on why it is building the Increment - Identify impediments to development for removal - Highlight and promote quick decision-making - Improve the Development Team’s level of knowledge - Created by the entire Scrum Team Sprint Review Note Although Sprint Planning starts by having the Product Owner discuss the objective that the Sprint should achieve and the Product backlog Items that, if completed during the Sprint, would achieve the Sprint Goal, the final Sprint Goal is created by the collaborative effort of the entire Scrum Team Daily Scrum - Held every day of the Sprint at the same place and time - The Development Team plans work for the next 24 hours - Max duration: 15 minutes - Attendees: All Development Team members - Held at the end of each Sprint - Inspect the Increment and adapt the Product Backlog if needed - Collaborate on the next things that could be done to optimize value - Max duration: 4 hours for a one-month Sprint - Attendees: All Scrum Team members and Stakeholders (Invited by the Product Owner) Sprint Review - Notes - The Sprint Review is not a demo - The presentation of the Increment is intended to elicit feedback and foster collaboration - Output: A revised Product Backlog that defines the probable Product Backlog Items for the next Sprint Page 5 of 8 Scrum Master - Sprint Review Product Backlog - Ensure that the event takes place - Ordered list of everything known to be needed in the Product - Single source of requirements for any changes to be made to the Product - Dynamic (it evolves) - It is never complete - If a Product exists, a Product Backlog exists too - Everyone should understand its purpose - Teach everyone to keep it within the timelimit Sprint Retrospective - Occurs after the Sprint Review and prior to the next Sprint Planning Note - Identify how the last Sprint went with regards to people, relationships, processes and tools If multiple Scrum Teams work on the same Product, only one Product Backlog is used - Identify and order the major items that went well and potential improvements - Create a plan for implementing improvements to the way the Scrum Team does its work - Max duration: 3 hours for a one-month Sprint - Attendees: All Scrum Team members Scrum Master - Sprint Retrospective - Ensure that the event takes place and attendants understand its purpose - Ensure that the meeting is positive and productive Product Backlog Items - Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint - Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning - Teach everyone to keep it within the time-box Note - Participate as peer team member from the accountability over the Scrum process Product Backlog Items can be updated anytime by the Product Owner or at the Product Owner’s discretion - Encourage the Scrum Team to improve Note During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with the product or organizational standards Scrum Artifacts - Product Backlog - Sprint Backlog - Increment Product Backlog Items - Attributes - Description Order Estimate Value May also include test descriptions that will prove the item’s completeness when “Done” Product Backlog Refinement - The act of adding detail, estimates, and order to items in the Product Backlog Page 6 of 8 - The Product Owner and the Development Team cooperate during refinement - The Scrum Team decides how and when refinement is done - Usually consumes no more than 10% of the Development Team’s capacity Note It is the sole responsibility of the Development Team to estimate items in the Product Backlog. Although the Product Owner may influence the team by helping it understand and select trade-offs, the people who will perform the work make the final estimate Sprint Backlog - The set of Product Backlog Items selected for the Sprint - A plan for delivering the Increment and realizing the Sprint Goal - Includes at least one high priority process improvement identified in the previous Retrospective meeting - Belongs solely to the Development Team. Only they can change it during a Sprint - Guides the Development Team in knowing how many Product Backlog Items it can select during a Sprint Planning Definition of “Done” - Notes - Multiple Scrum Teams working on the same Product must mutually define the definition of “Done” - If the definition of “Done” is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum - As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality - A new Definition of “Done”, as used, may uncover work to be done in previously “Done” Increments Sprint Progress - The Development Team tracks the total work remaining in the Sprint Backlog at least every Daily Scrum - Helps evaluate the likelihood of achieving the Sprint Goal Increment Release Progress - The sum of all Product Backlog Items completed during the Sprint and the value of Increments of all previous Sprints - A step towards a vision or a goal - Must be in usable condition regardless of whether the Product Owner decides to release it - The Product Owner tracks the total work remaining to reach a goal at least every Sprint Review - They compare this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work References Definition of “Done” - When a Product Backlog Item or an Increment is described as “Done”, everyone must understand what “Done” means - The definition of “Done” is used to assess when work is complete on the product Increment [1] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, et al. Manifesto for agile software development. https://www.agilemanifesto. org/, 2001. Page 7 of 8 [2] Ken Schwaber and Jeff Sutherland. The scrum guide. https://www.scrumguides. org/, November 2017. Page 8 of 8
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 8 Page Mode : UseOutlines Author : Title : Subject : Creator : LaTeX with hyperref package Producer : pdfTeX-1.40.18 Create Date : 2019:02:17 12:50:04+02:00 Modify Date : 2019:02:17 12:50:04+02:00 Trapped : False PTEX Fullbanner : This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3EXIF Metadata provided by EXIF.tools