Scrum Notes

Scrum

Principles of Scrum

  • Based on the Agile Manifesto.

  • Agile Manifesto values:

    • Individuals and interactions over processes and tools.

    • Working product over comprehensive documentation.

    • Customer collaboration over contract negotiation.

    • Responding to change over following a plan.

  • Values the items on the left more than the items on the right.

  • Jeff Sutherland: Do twice the work in half the time.


Certifications

  • Scrum Alliance, Scrum.org, Scrum, Inc.

  • PSM (Professional Scrum Master):

    • PSM I: Beginning level.

    • PSM II: Advanced Scrum certification (only 2% of PSM I holders have it).

    • PSM III: Very difficult Scrum certification (~1000 certified).


Definition of Scrum

  • A lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

  • Simple and purposefully incomplete to allow for adaptation and collective intelligence.

  • The rules of Scrum guide relationships and interactions.


Pillars of Scrum

  • Transparency: Everyone knows what is going on.

  • Inspection: Check your work as you do it.

  • Adaptation: Okay to change tactical direction.


Scrum Values

  • COURAGE: To do the right thing and work on tough problems.

  • FOCUS: Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

  • COMMITMENT: People personally commit to achieving the goals of the Scrum Team.

  • RESPECT: Scrum Team members respect each other.

  • OPENNESS: The Scrum Team and its stakeholders agree to be open about all the work and challenges.


Scrum Flow

  • Product Goal -> Product Backlog -> Sprint Planning -> Sprint Goal -> Sprint Backlog -> Daily Scrum -> Increment -> Sprint Review -> Sprint Retrospective -> 1 Scrum Team.


Scrum Roles

  • Product Owner

  • Scrum Master

  • Developers


Product Owner

  • Accountable for maximizing the value of the product resulting from the work of the Scrum Team.

  • Accountable for effective Product Backlog management:

    • Developing and communicating the Product Goal.

    • Creating and communicating Product Backlog items.

    • Ordering Product Backlog items.

    • Ensuring the Product Backlog is transparent, visible, and understood.

  • The Product Owner is one person, not a committee.

  • Represents the needs of many stakeholders.

Stances of the Product Owner

  • The Clerk, The Story Writer, The Manager, The Project Manager, The Subject Matter Expert, The Gate Keeper, The Visionary, The Collaborator, The Customer Representative, The Decision Maker, The Experimenter, The Influencer.

Conclusion Product Owner in “real life”

  • Is about long term planning.

  • Has a lot of “product manager” responsibilities.

  • Building the right thing is more important than “the best”/most valuable thing.

  • Bridge between organization (or sometimes customer) and development team.

  • Delegates the details of the Product Backlog (to the development team).


Scrum Master

  • Accountable for establishing Scrum as defined in the Scrum Guide.

  • Helps everyone understand Scrum theory and practice.

  • Accountable for the Scrum Team's effectiveness.

  • Serves the Scrum Team, Product Owner, and the organization.

  • Servant leaders.

Scrum Master: Knowledge & Skills

  • Scrum knowledge is important.

  • Good communication skills & knowledge about the organization.

  • Facilitating is more than making sure it takes place => it is also coaching.

  • Coaching according to the Scrum Guide:

    • Definition of Done

    • Valuable increments

  • Searching for impediments (what is holding back the team) and making sure they will be resolved.

Stances of the Scrum Master

  • COACH: Impediment remover, facilitator, coach, teacher, servant leader, manager, change agent, mentor.

  • SCRUM MASTER?: Scrum police, hero, scribe, secretary, JIRA, coffee clerk, chairman, admin, team boss


Developers

  • Committed to creating any aspect of a usable Increment each Sprint.

  • Accountable for:

    • 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.

Making Estimations

  • Developers make estimations so they can estimate the amount of work that can be planned.

  • Estimations are being used to estimate the price of features.

Accountability Developers

  • Developers are accountable for setting the sprint goal and committing the user stories in a sprint.

  • Changes to stories in a sprint are only allowed if discussed with the whole team including the product owner.

  • As a result of the accountability, estimations will be better.


Product Vision

  • In the form of an idea or roadmap

  • Vision is the result of the input from stakeholders


Sprints

  • Fixed length events of one month or less to create consistency.

  • A new Sprint starts immediately after the conclusion of the previous Sprint.

  • All the work necessary to achieve the Product Goal happens within Sprints.

  • During the Sprint:

    • No changes are made that would endanger the Sprint Goal

    • Quality does not decrease

    • The Product Backlog is refined as needed

    • Scope may be clarified and renegotiated with the Product Owner as more is learned.

  • Sprints enable predictability.

  • A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Sprints Length

  • In most cases 1 to 2 weeks.

  • Adaptations are allowed as long as the sprint goal will be reached.

  • If changes are too big, the sprint can be stopped => will “never happen”, in real life they accept the fact of not reaching the sprint.


Sprint Planning

  • Initiates the Sprint by laying out the work to be performed for the Sprint.

Sprint Planning Topics

  • Topic One: Why is this Sprint valuable?

    • The Product Owner proposes how the product could increase its value and utility in the current Sprint.

    • The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

  • Topic Two: What can be Done this Sprint?

    • Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.

  • Topic Three: How will the chosen work get done?

    • For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done.

Sprint and Sprint backlog

  • Developers create the sprint planning based on the prioritized backlog.

  • Velocity, the average achieved number of points over a number of sprints, aids in the accurate planning of the sprint.

  • Estimations are made in advance of the sprint planning using planning poker in story points.

  • Sprint goal is defined during the planning.

  • Throughout the sprint, developers continuously adjust to achieve the sprint goal. Monitoring is done through the burn down.


Daily Scrum

  • The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

  • A 15-minute event for the Developers of the Scrum Team.

Daily Scrum in Real Life

  • 15 minutes is the standard time slot

  • 3 topics for each person:

    • what I did

    • What I’m doing

    • What is blocking me


Sprint Review

  • The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.

  • The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.


Sprint Retrospective

  • The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

  • The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.

  • The Scrum Team identifies the most helpful changes to improve its effectiveness.


Product Backlog

  • An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

  • Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

  • The Developers who will be doing the work are responsible for the sizing.

Product Backlog: Order

  • Order is important because sprint refinements will happen from top to bottom

  • Product Owner regularly changes the order after discussing this with stakeholders and developers


Sprint Backlog & Sprint Goal

  • The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

  • The Sprint Backlog is a plan by and for the Developers.

Sprint Goal

  • Provides focus and meaning to a sprint.

  • Ensures clarity on what needs to be delivered as an increment.

  • Allows flexibility to adjust a sprint

Increment

  • An Increment is a concrete stepping stone toward the Product Goal.

  • Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.

  • Work cannot be considered part of an Increment unless it meets the Definition of Done.

Definition of Done

  • Aids in the quality of the delivered work.

  • Ensures transparency.

  • Provides clarity in estimating stories.

Refinement

  • Creating clarity about the stories to be delivered.

  • Making estimations using Scrum poker.

  • We utilize reference stories in this process.

Steering Committee

  • In almost every project, but not in Scrum Guide

  • Provides the actual client with a way to steer/control.

  • Scope, cost, time & quality (triple constraints)


Attention Points

  1. Scrum is not an excuse not to plan.

  2. Commitment in sprints is important.

  3. Clear and complete PBIs (Product Backlog Items) and SBIs (Sprint Backlog Items) (including status!).

  4. Meaningful daily scrums.

  5. Sprint retrospectives with follow-up on improvement points.

  6. Customers never give a “blank cheque”: budget estimations are needed

  7. Other project management techniques/methods can be combined with Scrum