You are on page 1of 9


INTRODUCTION This is a quick guide where I tried to comment all the main aspects of Scrum Guide (2011 version) in a sequenced way and adding some another minor aspects not shown in the Scrum Guide but commonly present in our projects. Notation: The texts between [brackets] are the additional comments not included in the official version of scrum guide, which you can find at You can find some texts in bold that are highlighted once they are important events, artifacts or roles within Scrum. I hope this guide can be useful as a quick reference guide your jobs or when studying. Any comments, corrections, suggestions, advices please feel free to contact me at Cheers, Glemiston Figueiredo Professional Scrum Master I

USING SCRUM FOR A NEW PROJECT IMPLEMENTATION 1.0 [Define the Product scope] 2.0 [Define stakeholders and committee] 3.0 SCRUM ROLE: SCRUM MASTER 3.1 Choose 1 person to be the Scrum Master 3.2 Train this person on SCRUM 3.2.1 Main points: Ensure Scrum Application Servant-Leader for: The Scrum Team (Product Owner and Development Team, as detailed later) The Entire Organization Leading and coaching the organization in its Scrum adoption; Planning Scrum implementations within the organization; Helping employees and stakeholders understand and enact Scrum and empirical product development; Causing change that increases the productivity of the Scrum Team; and, Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization 3.3 He or She can be or not a member of Development Team 4.0 SCRUM ROLE: PRODUCT OWNER 4.1 Choose 1 person to be the Product Owner 4.2 Train the Product Owner on SCRUM 4.3 Receives support from Scrum Master on: 4.3.1 Understanding long-term product planning in an empirical environment; 4.3.2 Understanding and practicing agility; and, 4.3.3 Facilitating Scrum events as requested or needed 4.3.4 Specific tasks detailed below 4.4 Concept 4.4.1 Maximizes the value of the Product and work done by the Development Team 4.5 He or She can be or not a member of Development Team 5.0 SCRUM ARTIFACT: PRODUCT BACKLOG 5.1 Product Owner analyzes the Product scope and delivers the first version of Product Backlog (named here as Initial Version) 5.2 One single product backlog for each product 5.2.1 ADDITIONAL SCRUM ARTIFACT: PRODUCT BACKLOG ITEMS List with the description of all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases Order the Product Backlog Items Often ordered by value, risk, priority, and necessity Top-ordered Product Backlog items drive immediate development activities Product Backlog Items and ordering must toward the ROI (Return of Investment) and TCO (Total Cost of Ownership) Product Backlog duration: while the Product exists



6.1 Define the people to join the Development Team 6.1.1 Development Team composition should not change within each Sprint 6.1.2 Quality goals remain constant within each Sprint 6.2 Train the Development Team members on SCRUM 6.2.1 Main Points: Self-managed and organized Cross-functional Can manage individual specialized skills although the accountability in shared and not individual for each Developer No sub-teams inside it Size between 3 and 9 members Product Owner and/or Scrum Master just are counted in this amount if they are also working as Developers 6.3 Receives support from Scrum Master on: 6.3.1 Coaching the Development Team in self-organization and cross-functionality; 6.3.2 Teaching and leading the Development Team to create high-value products; 6.3.3 Removing impediments to the Development Teams progress; 6.3.4 Facilitating Scrum events as requested or needed; and, 6.3.5 Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood. 6.4 7.0 SCRUM ROLE: SCRUM TEAM 7.1 Once the three people were assigned to the three Scrum roles (Scrum Master, Product Owner and Development Team), the Scrum Team was defined. 8.0 SCRUM ARTIFACT: THE SPRINT 8.1 1 month or less 8.1.1 8.2 ADDITIONAL EVENT: PRODUCT BACKLOG GROOMING 8.2.1 Occurs when Scrum Team decides to do it 8.2.2 Consumes no more than 10% of Development Team capacity 8.2.3 Participation of: Development Team and Product Owner Just Development Team Scrum Master doesnt participate but he/she can aid Product Owner: Delivering tools and techniques for Product Backlog management Teaching the Development Team to create clear and concise Product Backlog items Clearly communicating vision, goals, and Product Backlog items to the Development Team;




1st Version of Product Backlog (Initial Product Backlog Version) Revision of Product Backlog Items Detailing and grouping of Product Backlog Items Grouping Product Backlog Items Especially when working with multiple Scrum Teams on the same Product [Suggestion]: Group and Subgroup Product Backlog Items according to complete portions of processes, functionalities, tools or whatever will be developed, so, the Development Team can later easily choose subgroup items that can fit inside the sprint and delivers potentially usable product portions Review ordering of Product Backlog Items Estimation of Product Backlog Items More precise estimates are made based on the greater clarity and increased detail Output: 2nd Version of Product Backlog (named here as Working Version) Higher ordered Product Backlog items are clearer and more detailed More detailed Product Backlog Items has more precise estimates Product Backlog items selected to the upcoming Sprint are decomposed and fine-grained

8.3 SCRUM EVENT: SPRINT PLANNING MEETING: 8.3.1 All Scrum team participation (Development Team, Scrum Master, Product Owner) 8.3.2 Total of 8 hours (1 month Sprint) or proportionally less 8.3.3 SPRINT PLANNING MEETING - PART 1: Define what will be done 4 hours (1 month Sprint) Inputs: Product Backlog Last Product Increment Projected Capacity of Development Team Past Performance of Development Team Outputs:

Product Backlog Items selected to compose the Sprint Backlog Selected from the Product Backlog Defined by Development Team The selected Items must to be a set of shippable and deliverable portions of Product according to the DEFINITION OF DONE [Suggestion]: Try to deliver Product Backlog Item groups or subgroups that fit inside the Sprint and consist to complete portions of processes or functionalities Sprint Goal Defined by all Scrum Team (Product Owner, Development Team and Scrum Master)


SPRINT PLANNING MEETING - PART 2: Define how to get the work done Participation of invited people (besides of Scrum Team) to provide technical or domain advice Inputs: Select Items to compose the Sprint Backlog Define a Plan about how to convert the selected Product Backlog Items into a Product Increment Made by Development Team Forecast the work that can be done Work may be of varying size, or estimated effort Work planned for the first days of the Sprint is decomposed to units of one day or less Product Owner clarifications and negotiation Outputs: SCRUM ARTIFACT: SPRINT BACKLOG Consists to Selected Product Backlog Items + Plan to deliver them

8.4 ADDITIONAL EVENT: DAILY DEVELOPMENT WORK 8.4.1 Daily 8.4.2 Attend Product Backlog Items toward the agreed definition of done



Check Sprint Goal against the increment implementation If there is a sprint deviation, Development Team renegotiates the Sprint Backlog with the Product Owner Output: SCRUM ARTIFACT: INCREMENT Is the sum of all Product Backlog Items delivered since the first Sprint to the current or last one The increment must to be DONE It means that it must to be usable, regardless of the total completion of Product The DEFINITION OF DONE MUST TO BE clear and agreed between everyone in the Scrum Team The Increment delivered must to be a set of shippable and deliverable portions of Product according to the DEFINITION OF DONE

8.5 ADDITIONAL EVENT: MONITORING SPRINT PROGRESS 8.5.1 Made by the Development Team 8.5.2 At least once for every Daily Scrum 8.5.3 Only work remaining and date are important as parameters in Scrum 8.5.4 Input: Tracking of total work remaining 8.5.5 Output: Projection and reading of likelihood of achieving the Sprint Goal 8.5.6 [Suggestion]: Check that the Increment that are being prepared its becoming a set of shippable and deliverable portions of Product according to the DEFINITION OF DONE 8.6 SCRUM EVENT: DAILY SCRUM 8.6.1 Functioning: 15 minutes meeting Taken at the same time and place, daily Granted by Scrum Master Participation of: Just Development Team; Product Owner and Scrum Master participate just in case they are part of Development Team or if invited. 8.6.2 Consists to: Inspect the work done since last meeting What has been accomplished since last Daily Scrum

What will be done before till next Daily Scrum What obstacles were faced Check daily progress toward The Sprint Goal The Sprint Backlog Completion Define a plan until the next Daily Scrum 8.7 ADDITIONAL EVENT: DEVELOPMENT TEAM MEETING POST-DAILY SCRUM 8.7.1 Participation of just Development Team 8.7.2 Re-plan the rest of the Sprints work

8.8 ADDITIONAL EVENT: MONITORING PROGRESS TOWARD A GOAL 8.8.1 Made by the Product Owner 8.8.2 Made at least once before each Sprint Review. 8.8.3 Compare this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. 8.8.4 Time spent working on Product Backlog Items are not considered 8.8.5 Considers just the work remaining and desired delivery date 8.9 ADDITIONAL EVENT: SPRINT CANCELLATION 8.9.1 Only made by the Product Owner 8.9.2 It should happen just when the Sprint no longer makes sense given the current circumstances 8.9.3 It should happens every time Sprint Goal becomes obsolete, usually when: Company changes direction Market conditions change Technology conditions change 8.9.4 Cancellation Results: Review all completed and DONE Product Backlog Items Shippable parts of Product are usually accepted by the Product Owner Incomplete Product Backlog Items are re-estimated and put back on the Product Backlog 8.10 SCRUM EVENT: SPRINT REVIEW 8.10.1 Functioning: All Scrum Team and Stakeholders participation Informal Meeting 4 hours (1 month Sprint) 8.10.2 Concept: Technical point-of-view review Inspect the work done Define what to do in the next Sprint Adapt the Product Backlog if needed 8.10.3 Key Topics: For Product Owner: Identifies what was DONE or NOT DONE Discusses current Product Backlog status Projects likely completion dates based on current progress For Development Team: Issues review: Success points Problems faced Solutions taken ADDITIONAL ARTIFACT: INCREMENT PRESENTATION (here called SPRINT DEMO) Intended to elicit feedback and foster collaboration Answers questions about the Increment For the entire group: Collaboration about what to do next 8.10.4 Results: Revised Product Backlog Probable part of next Sprint Product Backlog Items


SCRUM EVENT: SPRINT RETROSPECTIVE 8.11.1 Functioning: After Sprint Review and before Next Sprint Planning Meeting 3 hours (1 month Sprint) 8.11.2 Purpose: Environmental point-of-view Review of ending Sprint: Checks aspects about people, relationships, process, and tools Identify and order: Success points Improvements to be done Create a plan for implementing improvements 8.11.3 Input: From Scrum Master: Encouragement of Scrum Team to improve the development processes and practices From All Scrum Team Plans ways to increase product quality through the adaptation of DONE definition [SUGGESTION]: Brainstorming to get the suggestions, based to a prior list of ideas by role 8.11.4 Output: List of Improvements to be implemented in the next Sprint 9.0 SCRUM ARTIFACT: SPRINT 2 SPRINT N 9.1 The Sprint process restart and ends: 9.1.1 Until the last agreed shippable part of product is delivered, according to the DEFINITION OF DONE 10.0 AFTER PRODUCT DELIVERY AND USING 10.1 Once the Product was delivered, the product lifecycle is still active so, we can repeat all the process in order to deliver maintenance shippable items 10.2 PRODUCT BACKLOG 10.2.1 After the product development be finished and the product delivered, it should be converted in a Maintenance Product Backlog Becomes larger once the product is used and gains value, and the marketplace provides feedback Can be changed because of changes in business requirements, market conditions, or technology