Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

How Leaders can support and leverage the Scrum Artifacts

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

 

Scrum Artifacts

In our final entry in the Scrum Guide companion for Leaders series (see parts 1, 2, 3, 4) we turn to the Scrum Artifacts.

Scrum’s artifacts represent work or value. They are designed to maximize the transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

  • For the Product Backlog, it is the Product Goal.
  • For the Sprint Backlog, it is the Sprint Goal.
  • For the Increment, it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

What is the Leader’s role when it comes to the Scrum Artifacts? Do they provide input into any of them? Are they involved in maintain them? How can they enjoy the transparency provided by them?

Leaders use the Scrum Artifacts as a window into the work of the Scrum Team. This transparency enables inspection and adaptation at the appropriate level while enabling the team to self-manage. 

Product Backlog

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. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the 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. The Product Owner may influence the Developers by helping them understand and select trade-offs.

Leaders respect the accountability of the Product Owner for the Product Backlog. The Product Owner will work with Leaders as stakeholders. They will make sure the Product Backlog is available and clear. The Product Owner and Scrum Team will be open to ideas from Leaders and other Stakeholders and will also have the courage to remain focused. 

Commitment: Product Goal

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

Scrum Teams are formed to execute the organization’s strategic decisions. Each Scrum Team’s Product Goal is a key mechanism to ensure this strategic alignment. Leaders are responsible for ensuring that the right conversations take place between Scrum Teams and their strategic stakeholders around the progress made towards the Product Goal and its relevance. Agility at a strategic level relies on the ability to inspect and adapt Product Goals and adjust course as needed. 

Sprint Backlog

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. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

The Sprint Backlog should not be used as a mechanism to control/manage the Developers on the Scrum Team or as a status reporting dashboard. 

Leaders should respect the Developers ownership of the Sprint Backlog and give them space to self-manage their work within the Sprint. They should avoid treating the Sprint Plan as a tool to manage the Scrum Team. The plan is for the Scrum Team and enables leaders to provide feedback. 

Commitment: Sprint Goal

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Leaders can use the Sprint Goal as a window towards the Scrum Team’s focus and commitment for the Sprint and should help the team achieve their Sprint Goal if the team reaches out for help. 

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. In order to provide value, the Increment must be usable.

The ultimate accountability of the Scrum Team is to make incremental progress towards the Product Goal or to learn that is not possible and either reframe the Product Goal or focus on something else. Leaders need to work with the Scrum Team to help them make progress often in spite of the environment that they are working within. They need to support the Scrum Team to work within the technical and procedural and cultural confines of the organization. 

Commitment: Definition of Done

The Definition of Done is a formal description of the state of each Sprint Increment when it meets the quality measures required for the product.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

The Definition Of Done makes what it means to be done transparent. It provides a mechanism to clearly communicate what it means to make progress, incrementally towards the Product Goal and therefore deliver value. It often provides a great way for the Scrum Team to set expectations with external groups. Leaders work with Scrum Teams to create and improve appropriate Definition of Done standards for the organization. Improving the organizations’ Definition of Done is a mechanism Leaders can leverage to raise the level of quality, professionalism, and transparency while letting the Scrum Team/s self-manage. Leaders provide support for Scrum Teams that are striving to achieve a more complete Definition of Done.

Subscribe for Email Updates:

Categories:

Tags:

User stories
Large Scale Scrum
Jira Cloud
RTE Role
DevOps
Presentation
Principles of Lean-Agile Leadership
Built-In Quality
Product Management
Lean Agile
AgileSparks
Continuous Delivery
Agile Basics
Sprint Iteration
Agile Delivery
Business Agility
AI Artificial Intelligence
Lean Risk Management
SAFe DevOps
Scrum With Kanban
Agile Marketing
Pomodoro Technique
AI
Professional Scrum Master
Risk-aware Product Development
Implementing SAFe
Risk Management in Kanban
LPM
ScrumMaster Tales
Keith Sawyer
Self-organization
System Integration Environments
Quality Assurance
RTE
Change Management
Agile Risk Management
Agile Release Planning
Atlaassian
Kaizen Workshop
Frameworks
Continuous Improvement
A Kanban System for Software Engineering
Agile Mindset
Agile Product Development
Slides
Effective Agile Retrospectives
Kaizen
Agile Games
LeSS
Agile Outsourcing
Lean Agile Basics
Tools
Continuous Integration
Lean Software Development
The Kanban Method
Value Streams
Agile Product Ownership
predictability
Agile and DevOps Journey
Agile Israel
Software Development Estimation
Lean Agile Leadership
Daily Scrum
Sprint Planning
ATDD vs. BDD
Engineering Practices
Team Flow
BDD
Advanced Roadmaps
transformation
Agile Exercises
Webinar
Agile
The Agile Coach
Enterprise DevOps
Agility
Entrepreneurial Operating System®
Certified SAFe
ROI
Product Ownership
Process Improvement
Lean-Agile Software Development
Lean Startup
Scrum Master
Scrum Primer
Games and Exercises
Reading List
Artificial Intelligence
Operational Value Stream
Scrum Master Role
SA
Release Train Engineer
TDD
LAB
SPC
RSA
An Appreciative Retrospective
Managing Risk on Agile Projects
WIP
Certification
Planning
Nexus Integration Team
PI Objectives
Agile Contracts Best Practices
What Is Kanban
Professional Scrum Product Owner
POPM
Professional Scrum with Kanban
System Team
agileisrael
Agile Testing Practices
Lean-Agile Budgeting
Agile Development
Agile in the Enterprise
Agile Project Management
Rovo
Atlassian
PI Planning
Accelerate Value Delivery At Scale
Rapid RTC
Covid19
Iterative Incremental Development
Agile India
Lean Agile Management
Limiting Work in Progress
ART Success
System Archetypes
Amdocs
Spotify
Managing Projects
Agile Project
ARTs
Perfection Game
Tips
NIT
GanttBan
ALM Tools
Agile for Embedded Systems
EOS®
Story Slicing
Video
Portfolio for Jira
Kanban
Releases Using Lean
Scrum
Risk Management on Agile Projects
SAFe Release Planning
Test Driven Development
lean agile change management
SAFe
Jira admin
Applying Agile Methodology
Nexus and Kanban
IT Operations
Code
Agile Israel Events
Lean Budgeting
Elastic Leadership
Kanban Game
Program Increment
Manage Budget Creation
Agile Program
Legacy Code
Scaled Agile Framework
Confluence
Scrum and XP
Nexus
Systems Thinking
Continuous Deployment
Achieve Business Agility
Scrum Values
Retrospectives
Continuous Planning
Acceptance Test-Driven Development
Software Development
ATDD
chatgpt
Jira Plans
Scrum Guide
Lean and Agile Techniques
Nexus and SAFe
Implementation of Lean and Agile
Legacy Enterprise
Agile Techniques
QA
speed at scale
Agile Release Management
Coaching Agile Teams
speed @ scale
Sprint Retrospectives
Lean Agile Organization
Kanban 101
Kanban Basics
Jira
Hybrid Work
Agile Community
Introduction to ATDD
Kanban Kickstart Example
Introduction to Test Driven Development
Agile Games and Exercises
Scrum.org
Development Value Streams
Agile Assembly Architecture
Lean and Agile Principles and Practices
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart