ScrumOn September 10, 2018 in agile • 5 minutes read
Table of Contents
Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
- Simple to understand
- Difficult to master
Scrum is made of:
- 3 Pillars
- 5 Values
- 3 Roles
- 3 Ceremonies
- 3 Artifacts
Transparency: Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
Inspection: Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.
Adaptation: If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted.
To bring to life the Scrum pillars, the Scrum Team embodies the following values:
- Commitment: People personally commit to achieving the goals of the Scrum Team.
- Courage: The Scrum Team members have 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.
- Openness: The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
- Respect: Scrum Team members respect each other to be capable, independent people.
Scrum Teams are:
- Self-organizing: the Team chooses how best to accomplish their work, rather than being directed by others outside the team.
- Cross-functional: the Team has all competencies needed to accomplish the work without depending on others not part of the team.
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
- The Product Owner
- The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
- The Product Owner is the person accountable for a well managed Product Backlog. The Product Owner may manage the backlog directly or have the Development Team do it. However, the Product Owner remains accountable. Effective practices for Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
- Development Team
- Does the work required for delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
- Scrum Master
- The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
- The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
- Sprint Planning
- Sprint Planning answers the following:
- What is the Sprint Goal?
- The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.
- What can be delivered in the Increment resulting from the upcoming Sprint?
- The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
- How will the work needed to deliver the Increment be achieved?
- Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
- Daily Scrum
- Focused on how the team is supporting the Sprint goal
- By the Team and for the Team (but others may attend)
- Stays on task and brief with 3 questions answered by everybody:
- What did you do yesterday (to support the sprint goal)?
- What are you doing today (to support the sprint goal)?
- What is impeding me (in supporting the sprint goal)? - Divergences are addressed offline outside of this meeting
- Sprint Review
- This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
- A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.
- During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
- Sprint Retrospective
- The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
- The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. They are delivered iteratively and incrementally, maximizing opportunities for feedback.
Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available. Supporting this practice is the “Definition of Done”, a group of conventions, standards and guidelines the Scrum Team must follow it as a minimum to help everyone understand what “Done” means.
- Product Backlog
- A list of features, prioritised by business value, timeliness and cost
- Each feature has an associated estimate, provided by the implementing team
- Backlog items have diverse sources and include technical improvements
- Sprint Backlog
- The Sprint Backlog represents the topmost items in the Product Backlog
- It’s loaded into the Sprint’s “timebox” for delivery
- The sum of all the Product Backlog items completed during a Sprint and the value of the previous Sprints Increments
- At the end of a Sprint, Increments are in a useable condition and meet the Scrum Team’s definition of “Done”.