Please enable JavaScript.

Coggle requires JavaScript to display documents.

SCRUM The 4 Events (Der SPRINT The heart of Scrum Container for all the…

- - - - FOR SHORTER SPRINTS
        Shorter sprints allow greater flexibility and control
        Reasons for Shorter Sprints
        
        Volatile market environment (new or volatile market, competitors, responsiveness to opportunities)
        
        Volatile team (more moments to look at and improve team dynamics to become proficient)
        
        Volatile technology (new technology, getting to know technology)
        
        Establishment of velocity stability (when forecasting of cost of a project can't be done on basis of similar project, with identical technology --> estimation of project costs is then based on short sprints at the beginning of a project)
        
        Provision of learning experience shorter sprints facilitate learning and build confidence
        
        Risk control gathering the cost and benefit information early in a project is critical, and shorter sprints provide this information so the project can be re-evaluated
      - LONGER SPRINTS
        Longer sprints are used when
        
        there is less risk, volatility, or uncertainty
        --> system used internally
        
        the pressures for the system is not competitive (time) but increased capability or lower cost
        
        REASONS AGAINST SHORTER SPRINTS
        
        Sprint overhead = increase time needed for planning and review (cost of insurance/cost of opportunity)
        
        2 days for 30 day sprint
        
        2 x 1,8 = 3,6 days for 2 x 14-day sprints
        
        4 x 1,5 = 6 days for 4 x 7-day sprints
        
        Loose time with natural ramp-up and wind-down of a new sprint
        
        project takes longer = higher costs
    - - NOT LESS THAN 1 WEEK
        
        actual work time to turn requirements into usable functionality inadequate
        
        too little time to build anything that is useable or provides valuable empirical information in less than 5 - 1,5 days = 3,5 days.
      - NOT LONGER THAN 1 MONTH because
        
        The stakeholder lose attention and forget about the project and to sync development with other business processes.
        
        As the number of requirements increases, the overall complexity increases in a fashion greater than linear (exponential, multi-exponential)
        --> To manager the increased complexity and remember prior decisions, DevTeam requires more documentation and design facilities.
        
        The amount of information to review and absorb and make decisions over, overwhelms the effectiveness of Scrum's short meetings.
- - - - time-boxed to max. 8 hours for a 1 month sprint - proportionally shorter for shorter sprints
        
        even when Sprint Planning hasn't been finished the meeting ends, work begins and the rest of the planning is to be finished as soon as possible on another occasion
      - Plan is created by collaborative work of the entire Scrum Team (PO, DT, SM)
        Mainly between PO & DT
        
        SM ensures that event takes place, the team understands its purpose and teaches how to keep it within time-box
    - - Topic 1
        1. WHAT CAN BE DONE THIS SPRINT?
        The entire Scrum Team collaborates on understanding the work of the 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 DEVELOPMENT TEAM
        works to forecast and estimate the functionality that will be developed during the Sprint. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
        
        INPUT
        
        Refined Product Backlog
        
        latest product Increment
        
        projected capacity of the DevTeam during the Sprint
        
        past performance of DevTeam (velocity)
        
        OUTPUT
        
        Product Backlog items selected for the Sprint Backlog
        
        Further Refinement of selected items
        
        Sprint Goal
      - Topic 2
        HOW WILL THE CHOSEN WORK GET DONE?
        Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
        
        THE DEVELOPMENT TEAM usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment.
        
        Work may be of varying size, or estimated effort. - However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint.
        
        Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.
        
        The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
        
        THE PRODUCT OWNER can help to clarify the selected Product Backlog items and make trade-offs.
        Negotiation with DevTeam
        
        If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner.
        
        The Development Team may also invite other people to attend to provide technical or domain advice.
        
        OUTPUT
        
        Sprint Backlog
        
        Sprint Backlog Items broken down into tasks
        
        Plan for doing the work (DevTeam)
        
        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.
      - SPRINT GOAL
        During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
        
        The Sprint Goal gives the Development Team some flexibility
        regarding the functionality implemented within the Sprint.
        
        The selected Product Backlog items deliver one coherent function,
        which can be the Sprint Goal. The Sprint Goal can be any other
        coherence that causes the Development Team to work together
        rather than on separate initiatives.
        
        As the Development Team works, it keeps the Sprint Goal in mind.
        In order to satisfy the Sprint Goal, it implements functionality and technology.
        
        If the work turns out to be different than the Development Team expected,
        they collaborate with the Product Owner to negotiate the scope
        of Sprint Backlog within the Sprint.
  - - - • What did I do yesterday that helped the Development Team meet the Sprint Goal?
      - • What will I do today to help the Development Team meet the Sprint Goal?
      - • Do I see any impediment that prevents me or the DevTeam from meeting the Sprint Goal?
    - - At it, the Development Team plans work for the next 24 hours.
        This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. **
      - The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.
        The DevTeam uses the Daily Scrum to inspect progress toward the Sprint Goal
        and to inspect how progress is trending toward completing the work in the Sprint Backlog.
      - Every day, the Development Team Members should understand how they intend to work together as a self- organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
      - The Development Team or team members often meet immediately after the Daily Scrum
        for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work in the spirit of self-organization.
- - - - PRODUCT OWNER
        
        • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
        
        • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
        
        Tragende Rolle, lädt ein, jedoch gibt das DevTeam die Hauptpräsentation
      - DEV TEAM
        
        • The DevTeam discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
        
        The DevTeam gives the main presentation of the developed functionality
        • The DevTeam demonstrates the work that it has “Done” and answers questions about the Increment;
      - ENTIRE GROUP
        (Scrum Team, Key Stakeholders)
        
        The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
        
        • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
        
        • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
    - - ATTENDEES INCLUDE
        
        the Scrum Team and
        
        key stakeholders invited by the Product Owner;
        
        The Scrum Master ensures that the event takes place and that attendees understand its purpose
      - DURATION
        
        This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.
        
        The Scrum Master teaches everyone involved to keep it within the time-box.
      - A Sprint Review is held at the end of the Sprint
        
        to inspect the Increment and
        
        adapt the Product Backlog if needed.
    - - During the Sprint Review, the Scrum Team and stakeholders and customers collaborate about what was done in the Sprint.
        
        demonstrate and test the functionality of increment
        
        customer feedback on increment (functionaly & quality criteria)
      - Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
        
        preview to next steps / sprint and stakeholders needs & wishes --> adapt Product Backlog
      - This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
      - A Sprint Review is held at the end of the Sprint to
        
        inspect the Increment and
        
        adapt the Product Backlog if needed.
- - - - SM ensures that the event takes place and that attendants understand its purpose.
      - The SM ensures that the meeting is positive and productive.
        
        The SM encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.
      - The SM participates as a peer team member in the meeting from the accountability over the Scrum process.
      - The SM teaches all to keep it within the time-box.