Please enable JavaScript.

Coggle requires JavaScript to display documents.

Agile - Coggle Diagram

- - - - Embrace Changes
      - Reduce Risk and cost:
    - - Adaptation
        Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection
      - Transparency
        Transparency enables inspection. Inspection without transparency is misleading and wasteful.
      - Inspection
        Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.
    - - Focus
      - Openness
      - Courage
      - Respect
      - Commitment
    - - Scrum Master
        
        Serves Team By
        
        ● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
        
        ● Causing the removal of impediments to the Scrum Team’s progress; and,
        
        ● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
        
        ● Coaching the team members in self-management and cross-functionality;
        
        Serves Product Owner By
        
        ● Helping find techniques for effective Product Goal definition and Product Backlog management;
        
        ● Helping the Scrum Team understand the need for clear and concise Product Backlog items;
        
        ● Helping establish empirical product planning for a complex environment; and,
        
        ● Facilitating stakeholder collaboration as requested or needed.
        
        Servers Organization By
        
        ● Leading, training, and coaching the organization in its Scrum adoption;
        
        ● Planning and advising Scrum implementations within the organization;
        
        ● Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
        
        ● Removing barriers between stakeholders and Scrum Teams.
      - Product Owner
        
        ● Developing and explicitly communicating the Product Goal;
        
        ● Creating and clearly communicating Product Backlog items;
        
        ● Ordering / triaging Product Backlog items; and,
        
        ● Ensuring that the Product Backlog is transparent, visible and understood.
      - Developers
        
        ● Creating a plan for the Sprint, the Sprint Backlog
        
        ● Instilling quality by adhering to a Definition of Done;
        
        ● Adapting their plan each day toward the Sprint Goal
        
        ● Holding each other accountable as professionals.
    - - Daily Scrum
      - Sprint Review
      - Sprint Planning
      - Sprint Retrospective
      - The Sprint
        
        Jargons
        
        Velocity vs Capacity video
        
        Stories
        
        Story Point
        
        Estimation Techniques
        Estimating Agile Way
        
        Poker Planning
        video
        
        Why estimate
        
        Metrics/KPIs
        
        Estimation Varience
        
        Scope Change
        
        Commitment Reliability
        
        Defect Leakage
        
        Capacity Utilization
        
        Backlog Health
        
        Velocity
    - - Sprint Backlog
      - Increment (Sprint Goal)
      - Product Backlog
    - - Do's
        
        Make sure the team sets and understands the sprint goal and how success will be measured. This is the key to keeping everyone aligned and moving forward toward a common destination.
        
        Do ensure you have a well-groomed backlog with your priorities and dependencies in order. This can be a big challenge that could derail the process if it’s not properly managed.
        
        Ensure you have a good understanding of velocity, and that it reflects things like leave and team meetings.
        
        Do use the Sprint Planning meeting to flesh out intimate details of the work that needs to get done. Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint.
        
        Leave out work where you won’t be able to get the dependencies done, like work from another team, designs, and legal sign-off.
        
        Finally, once a decision or plan is made, make sure someone captures that information in your project management or collaboration tool, like Azure boards or jira. That way, both the decision and the rationale are easy for everyone to see later.
      - Don'ts
        
        Don’t pull in too many stories, overestimate velocity, or pull in tasks that can’t be completed in the sprint. You don’t want to set yourself or your team up for failure.
        
        Don’t forget about quality or technical debt. Make sure to budget time for QA and non-feature work, like bugs and engineering health.
        
        Don’t let the team have a fuzzy view of what's in the sprint. Nail it down, and don’t focus so much on moving fast that you forget to make sure everyone’s moving in the same direction.
        
        Don’t take on a large amount of unknown or high-risk work. Break down stories that are large or have high uncertainty, and don't be afraid to leave some of that work for the next sprint.
        
        Don't ignore concerns from the team, whether it’s about velocity, low-certainty work, or work they think is bigger than what they estimated. Address the issue, and recalibrate when necessary.