1. This freeware mind map was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the Scrum framework and as a learning tool for candidates wanting to gain Scrum PSM qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)
1.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.
1.1.1. http://www.miroslawdabrowski.com
1.1.2. http://www.linkedin.com/in/miroslawdabrowski
1.1.3. https://www.google.com/+MiroslawDabrowski
1.1.4. https://play.spotify.com/user/miroslawdabrowski/
1.1.5. https://twitter.com/mirodabrowski
1.1.6. miroslaw_dabrowski
2. Scrum is a simple framework (not methodology) for effective team collaboration for building complex products (Scrum is not for project management). Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.
3. Free Scrum Tools Online
3.1. Planning Poker
3.1.1. http://www.planningpoker.com/
3.1.2. http://www.hat.jit.su/
3.1.3. http://www.planitpoker.com/
3.2. http://scrumbutt.me/
3.3. Velocity Range Calculator
3.3.1. http://www.mountaingoatsoftware.com/tools/velocity-range-calculator
3.4. Scrumpy
3.4.1. http://scrumpy.wikidot.com/
3.5. iceScrum
3.5.1. http://www.icescrum.org/
3.6. Sprintometer
3.6.1. http://sprintometer.com/
3.7. Scrumy
3.7.1. http://scrumy.com/
3.8. PangoScrum
3.9. Online Burndown Chart
3.9.1. http://www.burndownchart.nl/
3.10. scrumblr
3.10.1. http://scrumblr.ca/
3.11. TaskJunction
3.11.1. http://www.taskjunction.com/
4. Scrum Master Manifesto
4.1. http://www.scrummastermanifesto.org/
4.2. First created at the Scrum Alliance Global Gathering London,
4.2.1. 11-13 October 2011
4.3. 12 ScrumMaster Pocket Principles
4.3.1. 1. Dedicated Delivery Improver
4.3.2. 2. Foster Continuous Improvement
4.3.3. 3. Help Continuous Improvement
4.3.4. 4. Empower Coach Deliver
4.3.5. 5. Nurtures The Team
4.3.6. 6. Transparent Team Helper
4.3.7. 7. Commitment To Excellence
4.3.8. 8. Empathetic Evangelistic Guide
4.3.9. 9. Resistant Persistent Dedicated
4.3.10. 10. Help the Team
4.3.11. 11. Awareness Then Improvement
4.3.12. 12. Agile Driving Force
4.4. Top 10 things a ScrumMaster usually forgets to focus on (but is not SOLELY responsible for) ...
4.4.1. 1. Redefining career paths and goals to be more scrum focussed
4.4.2. 2. Missing Product Backlog items
4.4.3. 3. Team issues aren't being discussed because they are too uncomfortable
4.4.4. 4. Appropriate balance between end-to-end system test and unit tests
4.4.5. 5. Playing back the team's progress against the proposed release plan
4.4.6. 6. All tests roll up into the continuous integration results
4.4.7. 7. Team members realise the benefits of refactoring
4.4.8. 8. Code is regularly peer reviewed
4.4.9. 9. Pair programming is being utilised
4.4.10. 10. Definition of done is being expanded
5. Roles (3)
5.1. Scrum Team
5.1.1. a.k.a. The Pigs
5.1.2. Product Owner
5.1.2.1. Strategic Thinking
5.1.2.2. Voice of business
5.1.2.3. Responsibilities
5.1.2.3.1. Owns
5.1.2.3.2. Creates and maintains the Product Backlog
5.1.2.3.3. Chooses what and when to release
5.1.2.3.4. Represents stakeholders and customers to the Development Team
5.1.2.3.5. Determines requirements priorities
5.1.2.4. Recommended skills
5.1.2.4.1. Tolerate and manage change effectively
5.1.2.4.2. Shift gears/change course quickly and easily
5.1.2.4.3. Decide and act without having the total picture
5.1.2.4.4. Tolerate situations where things are up in the air
5.1.2.4.5. Tolerate and be comfortable with risk and uncertainty
5.1.2.5. May be
5.1.2.5.1. A Product Manager
5.1.2.5.2. An executive
5.1.2.5.3. A personnel manager
5.1.2.5.4. A customer
5.1.2.6. May NOT be
5.1.2.6.1. A committee
5.1.2.6.2. The Scrum Master
5.1.3. Development Team
5.1.3.1. Responsibilities
5.1.3.1.1. Owns
5.1.3.1.2. Creates the product Increment
5.1.3.1.3. Operates in a series of Sprints
5.1.3.1.4. Organizes itself and its work
5.1.3.1.5. Collaborates with Product Owner to optimize value
5.1.3.2. Characteristics
5.1.3.2.1. self-organizing / self-managing
5.1.3.2.2. cross-functional
5.1.3.2.3. autonomical
5.1.3.2.4. intensely collaborative
5.1.3.2.5. ideally static
5.1.3.2.6. ideally coolocated
5.1.3.2.7. recommended size 7 +/- 2 (commnication reasons)
5.1.3.3. May be
5.1.3.3.1. Software Developer
5.1.3.3.2. Engineer
5.1.3.3.3. Tester / QA
5.1.3.3.4. Architect
5.1.3.3.5. Graphic Designer
5.1.3.3.6. Technical Writer
5.1.3.4. May also be
5.1.3.4.1. Business Analyst
5.1.3.4.2. Database Specialist
5.1.3.4.3. User Interaction Designer
5.1.3.4.4. Requirements Engineer
5.1.4. Scrum Master
5.1.4.1. Responsibilities
5.1.4.1.1. Owns
5.1.4.1.2. Enacts Scrum values, practices, and rules throughout the organization
5.1.4.1.3. Removing the barriers between the development Team and the Product Owner so that the Product Owner directly drives development.
5.1.4.1.4. Teach the Product Owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
5.1.4.1.5. Improve the lives of the development Team by facilitating creativity and empowerment.
5.1.4.1.6. Improve the productivity of the development Team in any way possible.
5.1.4.1.7. Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
5.1.4.1.8. Keep information about the Team’s progress up to date and visible to all parties.
5.1.4.2. Recommended skills
5.1.4.2.1. Empathy
5.1.4.2.2. Inclusive
5.1.4.2.3. Trustworthy
5.1.4.2.4. Examine personal ethics
5.1.4.3. May be
5.1.4.3.1. A manager with appropriate servant-leader skills
5.1.4.3.2. A member of the Development Team
5.1.4.3.3. Selected by the Development Team
5.1.4.4. May NOT be
5.1.4.4.1. A Product Owner
5.2. Stakeholders (selected examples)
5.2.1. a.k.a. The Chickens
5.2.2. Business Owner / CEO
5.2.3. End-Users
5.2.4. Client
5.2.5. Consultants
5.2.6. Rooster
5.2.6.1. a chicken how struts around offering very loud and useless, uninformed opinions / information / input
5.2.7. Any other ...
6. Scrum Events (4)
6.1. Scrum Meetings
6.1.1. Sprint Planning Meeting
6.1.1.1. Watch: Sprint Planning Meeting
6.1.2. Dailiy Scrum
6.1.2.1. Watch: Sprint Planning Meeting
6.1.3. Sprint Review Meeting / Demo
6.1.3.1. Watch: Sprint Planning Meeting
6.1.4. Sprint Retrospective Meeting
6.1.4.1. Watch: Sprint Planning Meeting
7. Agile Techniques (not just in Scrum but general selected techniques in Agile)
7.1. 10 Intristic Motivators
7.2. BDD
7.3. Burn-Down Chart
7.4. Burn-Up Chart
7.5. CHAMPFROGS
7.6. Circle
7.7. Circles of Concern and Influence
7.8. Daily standups
7.9. Facilitated Workshops
7.10. Feature Progress Report
7.11. Five dysfunctions of a team
7.12. Future Backwards
7.13. Hapiness Door
7.14. Hapiness Index
7.15. Hapiness Metric
7.16. Kanban wall
7.17. Mad, Sad, Glad
7.18. MoSCoW
7.19. Modelling
7.20. Perfection Game
7.21. Personas
7.22. Planning Poker
7.23. Predictability Measure
7.24. Problem -> Goal -> Advantage
7.25. Product / Release Burndown Chart
7.26. Prototyping
7.27. Run your ass off
7.28. Speed dating
7.29. Sprinting / Timeboxing
7.30. Starfish
7.31. Story points
7.32. TDD
7.33. Task boards
7.34. The Sailboat
7.35. Timeline / Emotion Graph
7.36. Velocity
8. Scrum Products / Artifacts (3)
8.1. Product Backlog
8.1.1. What is it?
8.1.1.1. An ordered list of desirements
8.1.1.2. Potential features of the product
8.1.1.3. The single source of truth for what is planned in the product
8.1.1.4. Public and available
8.1.1.5. Has opportunities not commitments
8.2. Sprint Backlog
8.2.1. a.k.a. Team Backlog
8.2.2. Created by the Development Team during Sprint Planning
8.2.3. Often derived by examining and decomposing Product Backlog items (PBIs)
8.2.4. Might be a simple To Do list
8.3. Increment
8.3.1. What is it?
8.3.1.1. The Increment is the sum of all the Product Backlog items completed during the Sprint and all previous Sprints
8.3.2. Is usable and it works
8.3.3. Is potentially shippable
8.3.4. Must be DONE
8.3.4.1. As per Scrum Team standards
8.3.4.2. With no work remaining
8.4. Additional (outside Scrum)
8.4.1. Stories (type of PBIs)
8.4.1.1. User Stories
8.4.1.1.1. by Client / User
8.4.1.2. Technical Stories
8.4.1.2.1. by Scrum Team
8.4.1.3. Spike Stories
8.4.1.3.1. by Scrum Team for research
8.4.1.4. All stories should in line with:
8.4.1.4.1. INVEST
8.4.1.4.2. 3C
8.4.2. Product Backlog Item (PBI)
8.4.2.1. What is it?
8.4.2.1.1. Transparent unit of deliverable work
8.4.2.1.2. Contains clear acceptance criteria
8.4.2.1.3. May reference other artifacts like
8.4.2.1.4. Sized appropriately
8.4.2.2. Valid Product Backlog Items
8.4.2.2.1. Behaviors
8.4.2.2.2. Bugs / Defects
8.4.2.2.3. Chores
8.4.2.2.4. Constraints
8.4.2.2.5. Desirements
8.4.2.2.6. Epics
8.4.2.2.7. Features definitions
8.4.2.2.8. Non-functional requirements
8.4.2.2.9. Prototypes
8.4.2.2.10. Use Cases
8.4.2.2.11. User actions or stories
8.4.3. Program Backlog
8.4.3.1. Multiple products, high level
8.4.3.2. Used only in bigger projects
8.4.4. Product / Release Burndown Chart
8.4.5. Sprint Burnup Chart
8.4.6. Sprint Burndown Chart
8.4.7. Sprint Task
9. What is Scrum?
9.1. Scrum (n): A framework within which people can address complex problems, and productively and creatively deliver products of the highest possible value.
9.1.1. Scrum is dedicated for product management not project management
9.2. There is no Scrum methodology, no Agile methodology.
9.3. Scrum is:
9.3.1. One of the agile approaches
9.3.2. Lightweight
9.3.3. Extremely simple to understand
9.3.4. Extremely difficult to master
9.4. Watch: Introduction to Scrum
9.5. The Definitive Guide to Scrum
9.5.1. http://www.scrumguides.org/
10. Scrum Values (5)
10.1. The Scrum values are the values of self-organizing teams.
10.2. Many teams adopt Scrum practices without the Scrum values first ...
10.3. Commitment
10.3.1. Each person is committed to the project's goals
10.4. Respect
10.4.1. Team members respect each other
10.5. Focus
10.5.1. Everyone is focused on the work
10.5.2. A team that’s truly focused is not asked to multitask.
10.6. Openness
10.6.1. Each team member is aware of the work everyone else is doing
10.6.2. The Daily Scrum is all about openness
10.7. Courage
10.7.1. Team members have the courage to stand up for the project
10.7.2. It’s easy to talk about courage, but it’s a lot harder to show it when it means saying no to your boss about an important feature.
11. Agile fundamentals (agile in general not Scrum fundamentals)
11.1. Agile Manifesto
11.1.1. http://agilemanifesto.org/
11.1.2. 17 It industry veterans met at Snowbird Resort on February 11-13 2001 and created Agile Manifesto
11.1.2.1. Introduced 4 Values and 12 Principles defining Agile for Software Development
11.1.3. disciplines that gave rise to the Agile Manifesto
11.1.3.1. Extreme Programming, SCRUM, Dynamic Systems Development Method (DSDM®), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.
11.2. Agile Alliance
11.2.1. http://www.agilealliance.org/
11.3. Agile currently is buzzword, a marketing term
11.3.1. Agile is like any other newly introduced popular concept. “… Everybody is talking about it. Very few are doing it and those who are, are doing it badly” (James O. Coplien)
11.3.2. Agile as a word by it's own simply means - nothing more than merketing term.
11.3.2.1. there are so many Agile methodologies, Agile standards, Agile techniques, Agile tools, Agile good / best agile practices, Agile frameworks etc., that 'Agile' word itself is to general
11.3.2.1.1. see Agile World mind map
11.3.3. Agile is a generic description of a “Style of Working” and Philosophy.
11.3.3.1. Not only style of working on project but rather culture in ENTIRE organization including also it's management level, clients and partners
11.3.3.2. ‘Agile Project Management’ is perhaps an oxymoron
11.4. The Agile Mindset, Values and Principles
11.4.1. 4 Agile Value
11.4.1.1. 1. Individuals and interactions over processes and tools
11.4.1.2. 2. Working software over comprehensive documentation
11.4.1.3. 3. Customer collaboration over contract negotiation
11.4.1.4. 4. Responding to change over following a plan
11.4.2. 12 Agile Principles
11.4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
11.4.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
11.4.2.3. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
11.4.2.4. 4. Business people and developers must work together daily throughout the project.
11.4.2.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
11.4.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
11.4.2.7. 7. Working software is the primary measure of progress.
11.4.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
11.4.2.9. 9. Continuous attention to technical excellence and good design enhances agility.
11.4.2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.
11.4.2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.
11.4.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
11.4.3. The unlimited number of Agile Practices
11.4.3.1. The 'forest' of Agile Methods, Frameworks, Standards ...
11.4.3.1.1. see Agile World mind map
11.4.3.2. Being Agile vs Doing Agile
11.5. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks
11.5.1. In Agile community umbrella symbolizes different approaches in implementing Agile Manifesto but yet all from them are "Agilelish"
11.5.2. SCRUM, Lean, KANBAN, XP are not ‘Agile Project Management’ practices but rather team level practices
11.5.2.1. No Project Manager role
11.5.2.2. No project definition and etablished project / programme governance
11.5.2.3. ...
11.5.3. see Agile World mind map
11.6. Plan-Driven Projects vs. Change-driven Project Projects
11.6.1. Traditional (waterfall or sequential) Project Management metaphor
11.6.1.1. Railway metaphor
11.6.1.1.1. Moving forward, based on delivering predicted upfront requirements in accepted tolerances with limited tolerance to change, destination (final product specification) is known upfront and it will hardly change to any other destination
11.6.1.1.2. Changing course of train based on requirements
11.6.1.2. a.k.a. Plan-driven
11.6.1.2.1. build around paradigm of process
11.6.1.3. defined process control model
11.6.1.3.1. All work is understood before execution
11.6.1.3.2. Given a well-defined set of inputs, the same outputs are generated every time
11.6.1.3.3. Follow the pre-determined steps to get known results
11.6.2. Agile (iterative + incremental + adaptive) Project Management metaphor
11.6.2.1. Sailing metaphor
11.6.2.1.1. Embracing change of requirements, finding TRUE value for stakeholders by experimenting, testing, changing status quo.
11.6.2.1.2. Adapting / changing course of sailing based on business TRUE business needs and priorities, which could be different than requirements
11.6.2.2. a.k.a. Change-driven
11.6.2.2.1. build around paradigm of change / adaptation
11.6.2.3. empirical (adaptive) process control model
11.6.2.3.1. Frequent inspection and adaptation occurs as work proceeds
11.6.2.3.2. Processes are accepted as imperfectly defined
11.6.2.3.3. Outputs are often unpredictable and unrepeatable
11.7. Agile is best for complex projects
11.7.1. Simple (straightforward)
11.7.1.1. Everything is known and predicatable
11.7.2. Complicated
11.7.2.1. More is known than unknown
11.7.3. Complex
11.7.3.1. More is unknown than known
11.7.4. Chaotic (unpredictable)
11.7.4.1. Very little is known
11.7.5. See also Cynefin framework (by Dan Snowden)
11.7.5.1. different view on Cynefin Framework
11.7.5.2. https://www.youtube.com/watch?v=N7oz366X0-8
11.8. Agile is about delivering "best possible value" not maximum possible value
11.8.1. VALUE is NOT the same as BENEFIT
11.8.1.1. Benefits
11.8.1.1.1. Benefit is about outputs
11.8.1.1.2. Benefit is a objective
11.8.1.1.3. Benefit is an advantage to stakeholders (internal or external to the organization)
11.8.1.1.4. Benefit can be financial and non financial
11.8.1.1.5. Benefit can be ...
11.8.1.1.6. Benefit MUST be measurable and observable
11.8.1.1.7. Benefits are identifiable and quantifiable
11.8.1.1.8. Benefits SHOULD have baselines
11.8.1.1.9. Benefits SHOULD have priorities
11.8.1.1.10. Benefits types:
11.8.1.1.11. in general benefit = delivered requirements on time, on budget, within scope etc.
11.8.1.2. Value
11.8.1.2.1. Value is about outcomes
11.8.1.2.2. Value is subjective
11.8.1.2.3. Value can be measurable (if required but not natural to use such techniques in any Agile approach)
11.8.1.2.4. Value can be ...
11.8.1.2.5. Values SHOULD have priorities
11.8.1.2.6. in general value = designed fit for purpose, as small as possible solution
11.9. Agile is about focusing on business value / outcome, not strictly project plan / output
11.9.1. Focusing on value delivery not on fixed product definition or strict adherence to plan
11.9.1.1. That's why most Agile approaches define Project Vision
11.10. Agile respects the urgency and importance of priorities conveyed by the customer / user, most prominently by incremental delivery and flexible sequencing
11.11. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.
11.11.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)
11.12. Agile is about empowering people, treating them as intellectual individuals
11.12.1. “You have to learn to manage in situations where you don’t have command authority, where you are neither controlled nor controlling. That is the fundamental change.” (Peter F. Drucker)
11.13. Agile is about working closely and constantly (active two side collaboration) with customer throughout (including more than just feedback loops)
11.13.1. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)
11.14. Agile is about change, constant change which leads to better value
11.14.1. “If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt) is the method of choice“ (Ken Schwaber)
11.14.2. "Move Fast and Break Things" Mark Zuckerberg, Facebook
11.14.3. "Change is the only constant." Heraclitus, Greek philosopher
11.15. Agile thinking / approach often requires mind change and cultural shift
11.15.1. Not every organization is ready for that change!
11.15.2. "It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. this effort collapses somewhere in the hierarchy" (K. Imai, I. Nonaka, H. Takeuchi)
11.15.3. "Scrum exposes every cultural dysfunction that impedes developing software [...] It is not an approach or process that can be modified to fit the existing organizational culture; the culture must change to enable Scrum" (K. Schwaber, J. Sutherland)
11.15.4. “We cannot become what we need by remaining what we are.” (John C. Maxwell)
11.16. Why Agile Works?
11.16.1. 1. The customer's representative is in the driver's seat
11.16.2. 2. Quick reaction to the changing market and needs
11.16.3. 3. More visibility
11.16.4. 4. Ideal environment for development
11.16.5. 5. Self-manged teams
11.16.6. 6. Removes confusion and distraction
11.16.7. 7. No fortune tellers; Plan as you go
11.16.8. 8. Issues are less disruptive
11.16.9. 9. Continuous improvement