Scrum is a process framework to deal with nowadays technology, market, and environmental complexity, within you can employ various processes and techniques for
- developing (eg. work on complex adaptive problems),
- delivering, and
- sustaining products while
- productively and
- creatively deliver the highest possible value.
- Simple to understand but
- Difficult to master.
The framework consists of teams and their associated
- artifacts and
- the relationship and interaction rules that bind them together.
Each component serves a specific purpose and is essential to succeed.
Making efficacy and work techniques visible enables to continuously improve the product, the team, and the working environment. The essence is a small highly flexible and adaptive team scalable to several teams to cope with corporate scale collaboration to release complex work to arbitrary environments.
Pillars of Empiricism
Scrum is founded on empiricism and NOT a process, technique or definitive method. Uncertainty decreases over time as more is known improving predictability and risks likelihood estimation. Empirical process control (empiricism) is based on
- inspection and
Transparency is given by
- making significant aspects of the process visible to the responsible for the outcome so observers share a common understanding of what is being seen,
- a common language referring to the process shared by all participants and
- those performing complex work and those inspecting the increment share a common definition of done.
Inspection is done frequently but not affecting work by inspecting artifacts by participants or most beneficial diligently performed on the point of work toward a Sprint Goal to detect undesirable variances.
Adaptation is done asap whenever deviation in any process aspects or processed materials outside acceptable limits is detected and thus unacceptable affecting the increment or process.
Scrum embodies the values of
- commitment (achieving the team goal),
- courage (to solve also tough problems),
- focus (to sprint toward the team goal),
- openness (on challenges arising during performing the work) and
- respect (to strengthen individual capability and independence).
The values are exercised by living the rules of transparency, inspection and adaption as working with events, roles and artifacts.
The Scrum Team is primary led by requirements, cross-functional, self-organizing and consists of
- a Product Owner,
- the Development Team,
- and a Scrum Master.
Essential team characteristics are
- Cross-functionality (teams have all competencies needed to accomplish the work without depending on others not part of the team) and
- Self-organisation (teams choose how best to accomplish their work, rather than being directed by others outside the team)
Those team characteristics help continuously optimize
- creativity and
Proceeding in increments improve feedback and ensure potential useful work performed.
The Product Owner (one person, not a committee nor stakeholders) is accountable and responsible
- for maximizing the development work to product value ratio and
- as sole person for managing the product backlog.
The Product Owner is always accountable and must do the product backlog work below or have the Development Team do it by
- Requirements (Expressing clearly new and refine existing items in accordance with stakeholders and/or committees, regulations, policies etc.),
- Priority (Ordering the items in the Product Backlog to best achieve goals and missions),
- Value (Optimize the value of the work the Development Team performs),
- Consistency (Ensures visibility, transparency, clearness and shows what the Scrum Team will work on next)
- Understanding (Development Team understands the items to the level needed)
Essential team characteristics are
- Cross-functionality (Professionals who work during a sprint on a potentially releasable Increment at the end of each),
- Self-organisation (team choose how best to accomplish their work, structured and empowered by the organization),
- Equality (no titles, no sub-teams despite specialized skills and areas of focus),
- Solidarity (Accountability belongs to the team as a whole) and
- Size (Small enough <10 to remain nimble and large enough >2 to succeed with significant work within a sprint).
The Scrum Master
- promotes and supports Scrum within the organization,
- helps the Scrum Team as a servant leader to succeed and
- optimizes the interaction from outside maximizing the value created by the Scrum Team.
The Product Owner is supported by the Scrum Master in
- Product planing (in an empirical environment),
Product understanding (Scrum Team understands goals, scope, domain to the level needed),
- Product Backlog understanding (Development Team understands the items to the level needed),
- Backlog management (clear and concise items, techniques for effective management and maximizing value) and
- Scrum Events.
The Development Team is supported by the Scrum Master in
- Work to value maximization,
- Mitigate Impediments,
- Cope with legacy organizational units and
- Scrum Events.
The Organization is supported by the Scrum Master in
- Leading and coaching (in its Scrum adoption),
- Plan Scrum implementation (within the organization),
- Helping understand (to enact empirical product development),
- Increase productivity (Causing change that improves Scrum Team) and
- Increase effectiveness (With other Scrum Masters).
- is a time-box of one month or less which develops a useable potentially releasable product increment,
- starts immediately after the conclusion of the previous,
- short enough <=1 month to enable predictability (by ensuring inspection and adaptation) and long enough >2 weeks to cope with goal, complexity and risks,
- may be (very uncommonly) cancelled before the end in case a Sprint Goal becomes obsolete. (only by the Product Owner under influence from the stakeholders, the Development Team, or the Scrum Master). Potentially releasable work will typically be accepted by the Product Owner, the remaining must be put back on the Product Backlog and re-estimated.
During a Sprint
- no changes are made that would endanger the Sprint Goal (what is to be built),
- quality goals do not decrease,
- clarification of the scope must be renegotiated between Product Owner and the Development Team as more in known.
The Sprint hosts the formal prescribed and scheduled Scrum events. These time-boxes are specifically designed to provide critical transparency and inspection for adaption and can end when the purpose of an event is achieved:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
The Sprint Planning is a prescribed Scrum event with the prerequisites
- Product Backlog
- latest product Increment,
- projected capacity (Development Team)
- past performance (Velocity)
and below essential characteristics:
- Collaborative plan by the entire Scrum Team,
- Time-boxed to maximum of 8 hours for a one month Sprint (eg. shortened for shorter Sprints),
- Defines the deliverable product increment as Sprint Goal (Scrum Team),
- Identifies the Product Backlog Items that would achieve the Sprint Goal,
- Collaborates on understanding of the work that must be achieved and
- How will the work needed to deliver the increment be achieved.
The Product Backlog items selected and a plan for delivering them is the Sprint Backlog. The Sprint starts with Sprint Backlog items decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint. The Development Team may also invite other people to attend to provide technical or domain advice.
The Sprint Goal provides guidance to the Development Team on why it is building the Increment. Only the Development Team can assess what it can accomplish over the upcoming Sprint. The Development Team is able by the end of the Sprint Planning to explain how it intends to work as a self-organizing team to accomplish the Sprint Goal. Deviation in Sprint Backlog Scope must be renegotiated with the Product Owner.
The Daily Scrum optimizes the probability to meet the Sprint Goal, thus it
- is a 15 minute time-boxed internal event for the Development Team,
- is structured by the Development Team,
- improves communication and knowledge,
- identifies impediments,
- highlight and promote quick decision-making,
- is facilitated by the Scrum Master (time-box, execution, coaching attendants),
- is held every day at the same time and place of the Sprint (reduce complexity),
- forecasts upcoming work planned for the next 24 hours,
- inspects the work accomplished since the last Daily Scrum eg.
- monitors progress toward the Sprint Goal and trending toward completing the Sprint Backlog.
Detailed discussions often take place immediately after the Daily Scrum to adapt, or replan the rest of the Sprint’s work.
The Sprint Review is an informal meeting to elicit feedback and foster collaboration, thus
- it is held at the end of the Sprint by the Scrum Team and Stakeholders,
- it is facilitated by the Scrum Master (time-box, execution, coaching attendants),
- the attendees are invited by the Product Owner,
- the Product Owner explains what Product Backlog items have been accomplished (and what not),
- the Development Team demonstrates the work that it has accomplished and answers questions about the Increment,
- it inspects the Increment (attendees collaborate on what was done in the Sprint),
- the Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved,
- attendees collaborate on how the marketplace or potential use of the product might have changed what is the most valuable thing to do next eg. attendees collaborate on the next things that could be done to optimize value
- attendees collaborate on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning,
- it adapts the Product Backlog if needed,
- the Product Owner discusses the Product Backlog as it stands and states likely target and delivery dates based on progress to date if needed,
- reviews the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product and
- it is at most a four-hour meeting for one-month Sprint (for shorter Sprints, the event is usually shorter).
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
The Sprint Retrospective is led by the Scrum Master to encourage the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint, thus it
- takes place after the sprint review and prior to next sprint planning,
- is an opportunity for the Scrum Team to inspect itself (with regards to people, relationships, process, and tools),
- Identify and order the major items that went well and potential improvements ,
- create a plan for implementing improvements to the way the Scrum Team does its work,
- create a plan for identified improvements to be enacted during the next Sprint (adaptation to the inspection),
- it is a at most a three-hour meeting for one-month Sprint (for shorter Sprints, the event is usually shorter),
- it is facilitated by the Scrum Master (time-box, execution, coaching attendants),
- the Scrum Master ensures that the meeting is positive and productive and
- the Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process,
- increases the product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.
Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
Artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
The Product Backlog
- is the single source of requirements (business requirements, market conditions, or technology) for any changes to be made to the product,
- is an ordered list (higher usually clearer and more detailed than lower ordered) of everything that is known to be needed in the product,
- precise estimates are made by the Development Team (PO may help) based on the greater clarity and increased detail,
- is in the sole accountability and responsibility of the Product Owner,
- is never complete (living artifact),
- evolves over time as more is known like the environment surrounding,
- will be periodically refined (items are reviewed and revised to acquire higher degree of transparency; act of adding detail, estimates, and order to items) by the Product Owner in collaboration with the Development Team, but consuming not more than 10% of the Capacity of the Development Team,
- items that will be on upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box,
- items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning,
- dynamically changes to identify what the product needs to be appropriate, competitive and useful,
- exists as long the product exists and
- items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
The Product Backlog lists all
- enhancements, and
- fixes that constitute the changes to be made to the product in future releases.
Product Backlog items have the attributes of
- a description,
- value and
- optionaly test descriptions that will prove its completeness when “Done”.
When working with multiple Scrum Teams on the same product, one Product Backlos is used. A Product Backlog attribute (=epics) that groups items may then be employed.
Monitoring Progress Toward Goals
The total work remaining to reach a goal can be summed anytime, at least every Sprint Review by the Product Owner. This will be compared to previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
In complex environments, what will happen is unknown, thus forecast progress, like burn-downs, burn-ups, or cumulative flows can help but not replace empiricism. Only what has already happened may be used for forward-looking decision-making.
The Sprint Backlog is a forecast by the Development Team as subset of the Product Backlog items selected and a plan for delivering them as product increment according to “Done” definition realizing the Sprint Goal. Adaption requires at least one high priority process improvement identified by previous Retrospective meeting. As the Development Team proceeds during the Sprint and learns more about the work needed, the updated Sprint Backlog turns into progress that can be understood in the Daily Scrum. Only the Development Team is allowed to do so. The Sprint Backlog is highly visible.
Monitoring Sprint Progress
The total work remaining to reach a Sprint Goal can be summed anytime. The Development Team tracks progress by remaining work at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.
The product Increment is the sum of all completed Product Backlog items and the value of all increments accomplished by previous Sprints. An increment is regardless of whether the Product Owner decides to release in usable condition as per “Done” definition. An increment is inspectable accomplished work that copes with complies with empiricism. The increment represents a step forward to the product vision or goal.
Value optimization and risk based decision are based up on artifacts. Intransparent artifacts may flaw decisions, thus may diminish value and the risk may increase. The Scrum Master must work with the Scrum Team to understand if artifact transparency is warranted. In case incomplete transparency is detected by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results, the Scrum Master supports the organization to increase the transparency with appropriate practices. This journey usually involves learning, convincing, and change.
Definition of Done - DoD
The Scrum Team must share a common understanding of what “Done” means to ensure transparency and to assess when work is complete on the product Increment. This definition guides the Development Team in knowing its Sprint capacity for the Sprint Planning event, to deliver product Increments of potentially releasable functionality that adhere to current definition of “Done”, so the Product Owner may choose to release it. If this definition for an increment is part of conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If not, the Scrum Team must define a definition of “Done” appropriate for the product. Multiple Scrum Teams working on the same product must mutually define the definition of “Done”.
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. As Scrum Teams mature, higher quality is expected over time, thus new definitions of “Done” may uncover work to be done in previous increments.