Scrum, Agile

Get Started. It's Free
or sign up with your email address
Scrum by Mind Map: Scrum

1. Authors

1.1. Ken Schwaber

1.2. Jeff Sutherland

2. Events

2.1. Sprint

2.1.1. Container Minimizing risk Events Planning Daily Review Retrospective Development work

2.1.2. Maximum 1 month

2.1.3. No changes endangering sprint goal

2.1.4. No reduction of quality

2.1.5. Negotiable between dev team and PO as more is learned

2.1.6. Goal Enables inspection Enables adaptation

2.1.7. Can be cancelled by PO if goal is obsolete All done / completed items are reviewd All unfinisched items are re-estimated and put back on backlog

2.2. Planning

2.2.1. Maximum 8 hours

2.2.2. What can be delivered Chosen by dev team from the ordered backlog

2.2.3. How can it be delivered May renegotiate with PO May invite others

2.2.4. Input Backlog Last increment Projected capacity Past performance

2.2.5. Output Goal Crafted by scrum team Guidance to the dev team Anchor for potential negotiation of the scope Sprint backlog Selected backlog items Plan to implement Tasks for the next days

2.2.6. Formal event to inspect and adapt

2.2.7. Done by the whole scrum team

2.3. Daily Standup

2.3.1. Maximum 15 minutes

2.3.2. Synchronize activities What has be done for the sprint goal What will be done for the sprint goal What are the impediments For me For the dev team Project likelihood to reach Sprint Goal

2.3.3. Create plan for next 24 hours Inspect work of last day Inspect progress trend towards sprint goal Forecast work Optimizes probability to reach goal Adapt Improve communication Eliminate other meeting Identify impediments Improve knowledge Enables quick decisions

2.3.4. Same time Same place

2.3.5. Responsibility Dev team

2.3.6. Members Only dev team as participants Visitors are not allowed to participate

2.4. Refinement

2.4.1. Inspect increment

2.4.2. Adapt backlog if needed

2.4.3. Members Scrum team Stakeholders Invited by PO

2.4.4. What could be done next to optimize value

2.4.5. Maximum 4 hours

2.4.6. Output PO explains sprint log items done not done Lessons learned What went well What went wrong How were problems solved? PO discusses backlog Projected done dates Joint discussion of what to do next Review on how marketplace may have changed may impact next anticipated release Timelines Budget Capabilities Revised product backlog

2.5. Retrospective

2.5.1. Maximum 3 hours

2.5.2. What went well?

2.5.3. What are potential improvements? Plan to implement

2.5.4. Opportunity for self inspection People Relations Processes Tools

2.5.5. How can the definition of done be improved?

2.5.6. Members Scrum Team

3. Roles

3.1. Product Owner

3.1.1. Product Backlog Management Clearly expressing backlog items Visible Transparent Clear to all Shows what is done next Ordering by value Optimizing value of work Assuring the development team understands items to the level needed Ensuring transparency

3.1.2. Responsible as a person

3.2. Scrum Master

3.2.1. Servant leader

3.2.2. For PO Supporting development team on understanding the backlog Ensures scrum is understood and enacted Understanding and practicing agility Supporting PO on backlog management techniques Coaching PO on planning in empirical environment Facilitating events as needed

3.2.3. For dev team Coaching Self-organization Cross-functionality In environments where scrum is not fully understood and adopted Helping to create high value Removing impediments Facilitating events as needed

3.2.4. Organization Agile coaching Learing Convincing Change Planning scrum implementation Helping employees and stakeholders to understand and enact scrum Causing change to increase productivity Working with other Scrum Masters to increase productivity

3.2.5. Transparency Ensure artifact transparency Foundation for decision

3.3. Development Team

3.3.1. Cross-functional

3.3.2. Self-organizing

3.3.3. No titles

3.3.4. No sub-teams

3.3.5. Rsponsible as a whole

3.3.6. Size Minimum 3 Maximum 9

3.4. Team Model

3.4.1. Creativity

3.4.2. Flexibility

3.4.3. Productivity

4. Artifacts

4.1. Represents

4.1.1. Work

4.1.2. Value

4.2. Opportunities

4.2.1. Inspection

4.2.2. Adaptation

4.3. Goal

4.3.1. Maximize transparency of key information

4.4. Product backlog

4.4.1. Ordered list Features Functions Requirements Enhancements Fixes Attributes Description Order Estimate Value (Scrum team to implement)

4.4.2. Single source

4.4.3. Never complete

4.4.4. Living artifact

4.4.5. Refinement Ongoing process Not more than 10% of capacity When and how defined by scrum team Product backlog can be updated anytime by PO

4.4.6. Items that can be done within one sprint are marked ready

4.4.7. Progress toward goal updated at least every review by PO Burn-down Burn-up Cumulative flows

4.5. Sprint backlog

4.5.1. List of items from backlog for sprint

4.5.2. Plan to deliver increment

4.5.3. Evolves durring sprint

4.5.4. Can only be changed by dev team

4.5.5. Updated at least for every daily Scrum

4.6. Increment

4.6.1. Sum of completed backlog items from last sprint

4.6.2. Value of all previous increments

4.6.3. Additive to prior increments

4.7. Transparency

4.7.1. Responsibility of the SM to increase transparency

4.7.2. Responsibility of the SM to track any gaps in communication

5. Values

5.1. Commitment

5.2. Courage

5.3. Focus

5.4. Openness

5.5. Respect

6. Pillars

6.1. Transparency

6.1.1. Common language

6.1.2. Shared definition of done

6.1.3. Visible

6.2. Inspection

6.2.1. Frequent Not so frequent it blocks work

6.3. Adaptation

6.3.1. Adjustment when defined thresholds are not met

6.3.2. Events for inspection and adaptation All but the scrum container itself

7. Rules

7.1. Binding

7.1.1. Events

7.1.2. Roles

7.1.3. Artifacts

7.2. Governing

7.2.1. Relationships

7.2.2. Interaction

7.3. Described in the Scrum Guide

8. Framework

8.1. Targeting complex adaptive problems

8.2. Essential components

8.2.1. Scrum teams

8.2.2. Roles

8.2.3. Events

8.2.4. Artifacts

8.2.5. Rules

8.3. Attributes

8.3.1. Produces high value

8.3.2. Productive

8.3.3. Creative

8.4. Theory

8.4.1. Empirical process control

8.4.2. Knowledge comes from experience Decisions based on experience

8.4.3. Optimize predictability

8.4.4. Control risk

9. History

9.1. OOPSLA conference in 1995

9.2. The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka 1986

10. Related (non-original) Topics

10.1. Agile Manifesto

10.1.1. Individuals & Interactions over Processes & Tools

10.1.2. Working Software over Comprehensive Documentation

10.1.3. Customer Collaboration over Contract Negotiation

10.1.4. Responding to Change over Following a Plan

10.1.5. Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

10.2. User Stories

10.3. Information Radiators

10.4. Estimating

10.5. KPIs

10.6. Tools

11. Scaling

11.1. Scrum @ Scale

11.2. Nexus