Scrum PDF
Document Details
Uploaded by Deleted User
Tags
Summary
This document provides an overview of Scrum, a framework for iterative and incremental software development. It covers various aspects including Scrum theory, roles, responsibilities, and key meetings. The content uses diagrams, examples and links to external resources.
Full Transcript
What is Scrum Scrum Theory Scrum Values Roles and Responsibilities Key Meetings SCRUM Artifacts The Product Backlog User Stories Measuring Progress...
What is Scrum Scrum Theory Scrum Values Roles and Responsibilities Key Meetings SCRUM Artifacts The Product Backlog User Stories Measuring Progress Retrospectives Building the thing right 1 Scrum Definition from rugby: A scrum is a way to restart the game after an interruption, where the forwards of each side come together in a tight formation and struggle to gain possession of the ball when it is tossed in among them 2 Scrum is Simple iterative, incremental skeleton with some rules A collaborative effort involving developers and customers in ongoing dialogue A framework with multiple feedback loops and continuous inspection and adaption 3 An agile process that allows us to Scrum is focus on delivering the highest business value in the shortest time. Rapidly and repeatedly inspect actual working software. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint. 4 does not solve everything A silver bullet Scrum is Entirely new [ref: The New Product NOT Development Game] A process or a technique for building products Equipped with detailed plans for every contingency 5 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. Scrum Scrum employs an iterative, incremental approach to optimize predictability and Theory control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. http://www.scrumguides.org/scrum-guide.html 9 Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common Transparency understanding of what is being seen. For example: A common language referring to the process must be shared by all participants; and, Those performing the work and those accepting the work product must share a common definition of “Done” http://www.scrumguides.org/scrum-guide.html 10 Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable Inspection variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work. http://www.scrumguides.org/scrum-guide.html 8 If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that Adaptation the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. http://www.scrumguides.org/scrum-guide.html 9 The Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone when the following values are embodied and lived by the Scrum Team: Scrum Commitment Courage Values Focus Openness Respect http://www.scrumguides.org/scrum-guide.html 10 The Scrum Framework Daily Scrum Scrum Master Team Sprint Planning Sprint Review Sprint Iteration Retrospective (2-4 weeks) Backlog Product Backlog Sprint Backlog Grooming Potentially Shippable Product Owner Product Increment 11 The Scrum Framework Types of SP Daily Scrum SP 1 – planning w/ PO, finalizing the Standards met daily PO’s expectation to the project Daily stand up Scrum pillar inspection SP 2 – dividing the Product Backlog to What you need to do in a day user stories. SM make/solve impediments Note: only one(1) SM and only one(1) PO Two weeks sprint iteration is enough; it should be fixed (sprint duration) because of the mindsets & meeting schedules Roles and Responsibilities Defines the features of the product, decides on release date and content Product Owner Is responsible for the profitability of the product (ROI) Prioritizes features according to market value Can change features and priority every Sprint Accepts or rejects work results 13 Helps resolve impediments Roles and Responsibilities Ensure that the team is fully functional and productive Scrum Master Enables close cooperation across all roles and functions and removes barriers Shield the team from external interferences Ensures that the process is followed. Invites to daily scrum, iteration review. 14 Roles and Responsibilities The Cross-functional, seven +/- two Development members Team Selects the iteration goal and specifies work results Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal Organizes itself and its work Demos work results to the Product Owner 15 Sprint Planning The Product Owner and Team agree on the subset of the Product Backlog to work on this sprint. Result is the Sprint Backlog. Key Meetings Daily Standup (Daily Scrum) The Team understands its status every day in order to do a daily “inspect and adapt” cycle. Sprint Review The Team shows its Product to the Product Owner and other Stakeholders. The purpose is to “show off” and get buy off and feedback. Sprint Retrospective necessary. The Team (or Scrum Team) analyzes 18 Product Backlog Collection of “stuff” to be done Features, Capabilities, Issues, etc., often ill-defined Key Artifacts Anyone may add to the Product Backlog Prioritized by the Product Owner Sprint Backlog Work the team has signed up to do “Well-understood” Stories and Tasks Product Running, integrated, tested code Documentation Etc. PO can play around on Product backlog Dev team can only/ the only one who play around on sprint backlog 19 Impediments (perhaps in their own backlogs) – anything that slowing down the team Team: What is stopping the team from making progress today? Organizational: What is stopping the Other Artifacts organization from getting better? Sprint Burndown Chart Shows progress within a Sprint, indicates to the team if it will finish the Sprint Backlog. Product/Release Burndown Chart Shows progress across Sprints. Used to provide velocity metrics and make projections. 29 The Product Backlog PRODUCT BACKLOG Rule of Thumb Sample Product Backlogs The Backlog Iceberg Backlog Grooming 21 What is a Product Backlog? The list for work that is prioritized by the Product Owner Product Backlog What is a Product Backlog Item? Any item that appears in the Product Backlog This can be a User Story, Requirement etc. What is a Task? An individual step that describe how a Product Backlog item will be accomplished. 22 A Simple Backlog Items should be a few days worth of work Rule of Task should be a few hours work of work Thumb 23 Sample Product Backlog 24 The Scrum Framework Pig and Chicken Role of Pig and Chicken What are User Stories WRITING USER STORIES Examples 27 Mike Conh’s User Story template: User Stories ○ “As a ○ I want ○ So That ” User Stories are not complete without Acceptance Tests 28 Good User Stories What makes a Good User Story: I – Independent (of all others) N – Negotiable (not a specific contract for features) V – Valuable E – Estimable (to a good estimation) S – Small (so as to fit within an iteration) T – Testable (in principle even when there isn’t a test for it yet) 29 sample user story with acceptance User story - Example #1 Our first user story describes the webpage search feature: As a website user I want to able to search on the webpage So that I can find necessary information According to the Given/When/Then template, the acceptance criteria would be the following: Scenario: User searches for an item by its name “Given that I’m in a role of registered or guest user When I open the “Products” page Then the system shows me the list of all products And the system shows the “Search” section in the right top corner of the screen When I fill in the “Search” field with the name of existing item in the product list And I click the “Apply” button OR press the Enter key on keyboard Then the system shows products in the Search Results section with product names matching entered product name And the system shows the number of search results in the top of the Search Results section” User story - Example #2 The next example represents the acceptance criteria for a Feedback Form page. The user story would be the following: As a website user I want to able to submit feedback So that the website owners can consider my opinion or concern during future website updates Acceptance criteria for this piece of functionality would be: Scenario: User submits feedback form with the valid data “Given I’m in a role of logged-in or guest user When I open the Feedback page Then the system shows me the Submit Feedback form containing “Email”,“Name” and “Comment” fields which are required When I fill in the “Email” field with a valid email address And I fill in the “Name” field with my name And I fill in the “Comment” field with my comment And I click the “Submit Feedback” button Then the system submits my feedback And the system shows the “You’ve successfully submitted your feedback” flash message And the system clears the fields of the Submit Feedback form” Story Point Scales AGILE Relative Sizing ESTIMATING Exercise 33 Estimating As human being, we are not good at estimating 40 Estimating As human being, we are good at comparing, so… Agile estimation is relative estimation 35 Estimating How tall is the building? 36 Task Boards MEASURING Sprint Burndown Graphs PROGRESS 37 Task Board 38 Task Board 50 Task Board Task Board 41 Retrospectives RETROSPECTIVE Factual Retrospectives S Emotional Retrospectives 42 Retrospective Factual What went well What didn’t go well What needs to be improved 5-Star Diagram Start Doing Keep Doing Stop Doing Less of More of Emotional Mad, Sad, Glad 43 Retrospective What Went Well ○ Pairing ○ Resolved Impediment XYZ ○ More Tests What Could Be Improved ○ Room too hot ○ Too many interrupts ○ Continuous integration Broken 44 Resources THE AGILE MANIFESTO agilemanifesto.org The founding fathers of Agile. http://agilehandbook.com/agile-handbook.pdf Sommerville, I. Software Engineering 9th Edition, Addison-Wesley, 2011. Sommerville, Ian Software engineering / Ian Sommerville. — 9th ed.p. cm. Includes index. ISBN-13: 978-0-13-703515-1 ISBN-10: 0-13-703515-21. Software engineering. I. Title. QA76.758.S657 2011 005.1—dc22 2009053058 Ctto: TwistResource Company