# Scrum in Practice ## About
## Initiation * Define the Product Vision. * The ***PO*** will discuss with the stakeholders to define a product vision, that is clear and short. * The ***Scrum Master*** will help maintain this meeting as productive as possible. * Define the Product Strategy, which is how is the Product Vision be achieved. * Part of this is defining one or more Product Goals. * They are manifestations of the Product Strategy. * *They are keys for giving the **Scrum Team** a concrete strategy on what it needs to build to deliver a valuable product.* * The ***PO*** and entire ***Scrum Team*** should be evolved with ***Stakeholders*** to come up with the Product Goals. * Defining the Product Backlog. * Detailing everything necessary for the product, but with the right level of details. just-in-time * Meaning that we will detail just enough items for the upcoming Sprint. * In the beginning all the items will be ***EPICS***, an then will be refined to be more concise and specific. * Refinement can be done with ***User Stories*** this means: * Writing a Card which is a description of the functionality, valuable to a user or customer. Must be written from the perspective of a customer or user. * As `[actor]`, I want `[action]` so that \`\[end]. * Conversing, which represents the collaboration between the PO, the business people and Developers. * Confirming, which is a list of criteria that the Scrum Team will define to serve as verification if the product delivered suits the needs. * List of criteria that must be satisfied. (Just like *Test Cases*) * After creating the items, we now need to order them. Could be done ordering by: * Return on Investiment (ROI) * Value * How much value it will deliver. * Size * How much work has to be done the deliver this item. * Is it fast or slow. * The ROI takes both into consideration by $$\frac{value}{size}$$. * Risk * A riskier User Story is the one that depends on things that the Scrum Team is not familiar with. * And they should have higher priority, since if they don't work, less waste will have been produced. * Dependencies * The dependencies between User Stories must be also considered. * If a higher ROI item depends on a lower ROI one, the lower one will still have to be done before. * Define the business value using Kano. * How can infer the value of User Stories? * With the Kano Model: * Classify the Backlog items in: * Mandatory. (Higher priority) (All of them must be at the Backlog) * Linear. (Medium priority) * Exciter. (Less priority) (Should have a few) * But, to be able to order we first need to be able to estimate the values: * This will be done with Story Points and Planning Poker. * Story Point will be in a scale of: `1, 2, 3, 5, 8, 13, 20, 40, 100`. * It is a team metric. * The estimation itself will be done with Planning Poker. * A collaborative consensus based agile estimating technique. * For the first time, you will select the smallest and easiest User Story, and give it a Story Point of 2. The other ones will then be relative to this one. * Construct the Definition of Done: * Sets of Criteria like: * Quality assurance * Architecture * Non-functional requirements * Process management * Configuration management * You can also define Done in different levels: * Task * Product Backlog Item * Sprint (Increment) * Release * Project * Form the Scrum Team, considering: - Hard skills: *(There must be redundancy here - multiple devs with same circle of knowledge - otherwise they cannot help each other)* - Technical Factors: - Knowledge about methodologies, - Processes, - Technologies, - Tools - Soft skills: *(How well they work as a team)* - Social Factors. - How good is their communication. - Personality. - Interpersonal Abilities. - Individual Costs. - You can bring all the candidates members together and let them organize into Scrum Teams. - Or make existing teams propose the new Scrum Team. * Now you develop a **Release Plan** to bring alignment with the team and choose the Backlog items to be in the release. * It can be built with a Feature-based approach: * Fixed Scope, but let Time flexible. * Select a set of Project Backlog items and plan how to deliver them. * Or can be built with a Date-driven approach: * Fixed deadline, flexible scope. * Now you can estimate how many sprints it will take to burn all the Story Points to get this release done. * You will create the Best and Worst case scenarios, discussed in the Cone of Uncertainty. * You can use historical data, on how many points usually the team can burn in 1 Sprint. * Otherwise you will have to predict the velocity: * By analyzing a Backlog Item, an how many hours it would take to complete it. * You must consider that the team wont have 100% effectiveness, it will be from 55% to 80%. * So if they in total work 100 *NOMINAL* hours per week, they will in practice work only 55 to 80 *REAL* hours. * If this Backlog item has 10 points, and the team can complete it in the Sprint in 50 hours, then it will take them 5 hours/print. * Thus they would be able to burn in a Sprint $$\frac{55}{5} = 11$$ to $$\frac{80}{5} = 16$$ points. * The Release Plan must be updated at the end of every Sprint, in the Sprint Review. * You never decide the Sprint Length after you pick the User stories for the Sprint. ## Planning * Refining the Product Backlog items can happen: * During the Sprint Planing. * Or by having a separate Refining Meeting. * In the Sprint Planning: * Must Address: * Why is this Sprint valuable? * Discuss the opportunities to increase the products value and utility. * How this can address this. * Scrum Team defines a Sprint Goal: * It communicates why the Sprint is valuable to all stakeholders, brings transparency. * Sprint Goals should not be defined after selecting the Backlog items. * What can be Done this Sprint? * Break down EPICS into smaller User Stories. * Define how much can be completed during the Sprint: * See upcoming capacity: * How many hours available the Devs have for this Sprint. * If anyone will be off the office. * Could consider past performance or consider the Team Velocity. * How will chosen work get Done? (The Plan) * Create the Sprint Backlog and the Plan: * Decomposing the Product Backlog Items * Team can design a sketch of the solution, to have an overview of what needs to be done. * After decomposing and learning more, you gather and check if more can be included, if things need to be removed, always thinking in the Sprint Goal. * Then you have a Sprint Backlog. * After the Sprint Planning is finished: * ONLY the developers can change the Sprint Backlog. * And the Sprint Backlog is the ONLY source of work for them. ## Execution * The Sprint is when the done usable potentially releasable product increment is created. * Developers should not be interrupted with demands that are not focused on the Sprint Goal. * During the Sprint in Software Development this is executed: * Requirements * Architecture * Design * Implementation * Testing * Unit Testing * Integration Testing * System Testing * Ideally, the Scrum team does all the work necessary to deliver the product. * But in some cases, part of the work will be done by external team. * The Daily Scrums: * The developers don't plan only in the Sprint Planning, they also plan daily with the Daily Scrums. * To talk about their progress and synchronize work. * Each one must answer: * What did I do since last meeting? *(Can be ignored, to only discuss the future)* * What will I do until next meeting? * Do I have any Impediments? * Tips on Daily Scrum: * Don't share shallow information. * Don't discuss technicalities. * Sprint Burndown are usually done in the Daily Scrums. * 6 indicators of bad Daily Scrums: * Team members are reporting status to Scrum Master or PO. * Some members arrive late. * Taking more than 15 minutes. * People share shallow information. * Some members don't pay attention to what others say. * Scrum Master or PO manage turns. * When the Sprint is almost over, an everything is almost Done, the Team could refine some Product Backlog Items for the next Sprint. * IF there are disturbances in the Sprint, you cannot blindly follow the Scrum rules. - You might have to cease a bit if necessary depending on the case. * What to do with Product Backlog items that are not Done by the end of the Sprint? * The incomplete items are moved back to the Product Backlog. ## Inspection and Adaptation * The Sprint Review (The goal is to inspect the Increment and adapt the Product Backlog if needed) * The developers will check which Backlog items are Done. * And prepare them to be demonstrated in the Review. * Inspection: * After getting the feedback from the users and stakeholders. * The Scrum Team will discuss the Product backlog. * Given the release plan, the PO might discuss the likely target and delivery dates, by using the Release Burndown chart. * Product Backlog Grooming: * Usually the grooming is not done in the Review, since it takes a lot of time, and the review should be used to rise these feedbacks. * These can be part of the Backlog Refinement Sessions on Sprint Planning. * Or in separated Workshops after the Sprint Planning. * The PO doesn't need to wait until the Sprint review to inspect and give feedback to the developers on what has been done. * Don't rely only in the Sprint Review to get feedback from Users and Customers. * The Sprint Retrospective * Avoid using the same methods in the Sprint Retrospective. * Questions to be anwsered: * What went well during the Sprint? * What didn't go well? * How can we improve? * 5 steps of the meeting: * Setting the stage. * Welcome people and reiterate how important the meeting is. * Review the Improvement List. * Presente meeting structure. * Gather data. * Gather all that happened, for good or bad during the Sprint. * Generate insights. * Improvement Points. * Lessons Learned. * Decide what to do. * Which actions will be put for next Sprint. * The most impactful improvements are addressed as soon as possible. * The may even be added to the Sprint Backlog for the next Sprint. * Treat improvement items as backlog items: * Retrospective Planning Poker. * Close the meeting.