Scrum – Framework

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

15 Elements of Scrum

3 Roles 3 Artifacts 5 Events 3 Commitment 1 Activity
1. Product Owner
2. Scrum Master
3. Developers
1. Product Backlog
2. Sprint Backlog
3. Increment
1. Sprint
2. Sprint Planning
3. Daily Scrum4. Sprint Review
5. Sprint Retrospective
1. Product Goal
2. Sprint Goal
3. Definition of DONE
1. Product Backlog refinement
Each role in Scrum has a specific accountability Artifacts raise transparency Events are opportunities to Inspect and Adapt

Scrum Values

  • Courage
  • Focus
  • Openness
  • Respect
  • Commitment

Scrum Principles

  • Empiricism
    • Transparency
    • Inspection
    • Adaptation
  • Base – Trust & Courage
  • Self-Management
Product Owner Developers Scrum Master
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team
The Product Owner is also accountable for effective Product Backlog management, which includes:
1. Developing and explicitly communicating the Product Goal;
2. Creating and clearly communicating Product Backlog items;
3. Ordering Product Backlog items; and,
4. Ensuring that the Product Backlog is transparent, visible and understood.
Developers are always accountable for the following:
1. Creating a plan for the Sprint, the Sprint Backlog;
2. Instilling quality by adhering to a Definition of Done;
3. Adapting their plan each day toward the Sprint Goal; and,
4. Holding each other accountable as professionals
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices within the Scrum framework.

Scrum Artifacts and Commitments

Product Backlog Sprint Backlog Increment
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
An inventory of things to be done on the product. An ordered list of everything that might be needed in the product. Single source of repository for the Development Team to pull the work from.
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
Direction and Focus for the Scrum team to achieve the Sprint Goal. Raises Transparency within the Scrum Team
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. To provide value, the Increment must be usable.
A working product to release to the Production that formulates the Sprint Goal.
Raises Transparency within the Scrum Team and with the Stakeholders
The Product Goal describes the future state of the product, which can serve as a target for the Scrum Team to plan against. First, the Product Goal is in the Product Backlog. Then, the rest of the Product Backlog emerges to define “what” will fulfil the Product Goal. The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility regarding the exact work needed to achieve it. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
In short, DoD is a shared understanding within the Scrum Team on making your Product Increment releasable.
DONE = Releasable

 

Scrum Events

Event Inspect Adapt Participants Timebox
Sprint Product Goal and Product backlog Increment Scrum team 1 Month
Sprint Planning Product Backlog, available Capacity or Velocity,  Definition of Done and Retrospective Improvements (optional) Sprint Backlog
Sprint Goal – Why , Forecast (the Product Backlog Items/requirements) -Why and Plan to deliver the Forecasted Product Backlog Items – How
Scrum team (Scrum Master + Product Owner + Developers) 8 hours for 1 Month and usually short for a shorter duration
Daily Scrum Progress towards the Sprint = Sprint Backlog (Goal, Forecast, Sprint Backlog) Day plan, i.e. Updated sprint backlog Developers are a must.
SM and PO are optional (both can participate as Developers if actively working on the Sprint work)
15 Minutes
Sprint Review Increment created by Development Team, Product Backlog, and Current business conditions The feedback that helps the Product Improvements and gets adapted to the Product Backlog Scrum Team (Product Owner + Developers  + Scrum Master) and Stakeholders 4 hours for 1 Month and usually short for a shorter duration
Sprint Retrospective Process and Practices, People and Relationships and the Definition of Done Actionable process  improvements Scrum Team Members (Product Owner + Developers + Scrum Master) 3 hours for 30 days and usually short for a shorter duration of time

 

Product Backlog Refinement

Product Backlog refinement is an act of breaking down and further defining Product Backlog items into smaller, more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. However, the Product Owner may influence the Developers by helping them understand and select trade-offs.

Scrum Rules

  • One Product – One Product Owner and One Product Backlog, no matter how many teams work on that product.
  • All the work Developers must originate from the Product Backlog
  • No Changes to be made during the Sprint that endanger the Sprint Goal
  • Only the Product Owner can Cancel the Sprint in case the Sprint Goal Obsolete
  • Each event in Scrum is Timeboxed
  • The Scrum team must create the Definition of DONE
  • Only developers create the estimates after clarifying their doubts with the Product Owner
  • The next Sprint immediately after the previous Sprint is concluded – There is no time in between the Sprints
  • The Scrum team must create a potentially releasable increment at the end of every Sprint
  • There are no titles, or designations, just accountabilities – PO, SM, and Developers.
  • Scrum recognizes no sub-teams (DB, UI, UX, Dev, Test), and neither does it recognize any phases (Analysis, Design, Coding).
  • If Scrum is reduced to one purpose only, it would be to create a ‘Done’ Increment” which is usable.
  • Sprint length remains unchanged during the Sprint
  • To provide value, the Increment must be usable
  • The emergent process and work must be visible to those performing the work as well as those receiving the work.
  • The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.
  • The adjustment must be made as soon as possible to minimize further deviations
  • For Product Owners to succeed, the entire organization must respect their decisions
  • The Sprint Goal must be finalized before the end of Sprint Planning.

The Product Goal is the long-term objective for the Scrum Team. Therefore, they must fulfil (or abandon) one objective before taking on the next.

Author's Bio

A Professional Scrum trainer (PST) from Scrum.org, SAFe® Program Consultant (SPC 4.5) and experienced Spotify consultant with over 14 years of rich experience in building people, Sumeet’s mission drives him to build people and help them learn who they are and how they want to show up in the Agile world.