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
Scrum Roles
Although the scrum roles are closely interrelated, each role in Scrum has a specific set of responsibilities.
| 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 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
Artifacts raise transparency in detailing the product being developed. All the 3 artifacts are important. However, the increment is often thought of as the most critical of the three artifacts of Scrum.
| 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 Developer
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 fulfill 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 1 Month 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 fulfill (or abandon) one objective before taking on the next.
Find Our Upcoming Training
Sign up for Agilemania Newsletter
Stay updated with the latest Agile & Scrum trends.
Sumeet Madan
With a remarkable 18-year tenure in software engineering, agile training, coaching, and consulting, Sumeet's expertise is unparalleled. As a certified Professional Scrum Trainer (PST) from Scrum.org and a distinguished SAFe® Practice Consultant (SPC), Sumeet brings a wealth of knowledge and skill to every project, making a lasting impact on organizations seeking to embrace Agile methodologies.
WhatsApp Us
