DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Non-Traditional Project Planning
  • Sprint Goals: How to Write, Manage, and Achieve
  • Compatibility Testing: Checklists and Crucial Things You Need to Know About It
  • Conducting Sprint Retrospective Meetings

Trending

  • Next.js vs. Gatsby: A Comprehensive Comparison
  • What You Must Know About Rate Limiting
  • Common Problems in Redux With React Native
  • Breaking Free From the Cloud With Kamal: Just Enough Orchestration for Your Apps
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. What Are We Really Committing to in Scrum?

What Are We Really Committing to in Scrum?

Since commitments are now forecasts according to the Scrum Guide, are team members expected to commit to anything of substance these days?

$$anonymous$$ user avatar by
$$anonymous$$
·
May. 29, 19 · Opinion
Like (1)
Save
Tweet
Share
5.49K Views

Join the DZone community and get the full member experience.

Join For Free

Commitments in Scrum

What are we committing to again?
"The Sprint Backlog is a forecast by the Development Team."

In 2011, the language used in the Scrum Guide to describe a Sprint Backlog was significantly revised. Up until that point, the work selected by a team for actioning in a Sprint was referred to as a commitment. From then onwards, it would be acknowledged instead as being a forecast. That is still the language used in the Guide today, even though subsequent versions have codified "commitment" to be a Scrum value, and teams are expected to engage in commitment-based planning.

Since the term "forecast" is somewhat weaker than "commitment,"though, we can perhaps be forgiven for wondering what exactly is going on. Are team members expected to commit to anything of substance these days? If so, what ought it to be?


Well, the Scrum Guide also says that "people personally commit to achieving the goals of the Scrum Team." There's our clue. The Sprint Backlog is, in truth, a forecast of the work needed to achieve the most essential goal in the Scrum Framework -- the Sprint Goal -- and that's what they should commit to. A Product Backlog, meanwhile, can be seen as a longer-term forecast, matured through continuous refinement, about the work that is likely to be delivered in upcoming Sprints.

Remember that, in Scrum, the Sprint Goal does not change at any point during the iteration. If it ceases to be viable, then the Sprint ought to be cancelled and a new one planned immediately. That's how critical the Sprint Goal is. It's an immutable point of reference against which other things should evolve and emerge in light of discovery. It is the Sprint Goal, and not the Sprint Backlog, which represents the more artful team commitment. In essence, measuring how much work is left in the Sprint Backlog ought to be nothing more than an exercise in forecasting goal actualization.

The implications of this can send many agilists into conniptions. A team should clearly make a good forecast in order to have transparency over the work remaining in a Sprint. That forecast could turn out to be wrong, however, perhaps with no story being completed at all by the end of the timebox, and yet the Sprint Goal could still be met by a competent team with a useful increment delivered. Valuable work will have been performed which meets the Definition of Done and the Sprint Goal, and which is fit for potential release. That work will have been "done" and invested in the increment. The purpose of Sprint Backlog items is to provide transparency over work in progress, but their actual completion is, strictly speaking, quite immaterial.

Forecast 

Forecast is Pattern of the Month at agilepatterns.org

Intent: Predict completion time based on the estimated size of a backlog and a known velocity

Proverbs:

  • If we are to understand the future we must look at the past.
  • Forewarned is forearmed.

Motivation: Agile teams must be prepared to respond to change, and cannot always make a delivery commitment. Yet even in conditions of extreme uncertainty, it is valuable to have a provisional timeline based on existing data and clear assumptions.

Structure: A team has an ordered backlog of items to deliver. The team only allows a limited number of items to be work in progress at any one time. The velocity or throughput can be calculated by inspection and a forecast made regarding the likely time of delivery for items remaining in the backlog. Metrics are captured iteratively on a timeboxed basis. The method used to derive these metrics and make such forecasts can be adapted by the team in order to improve their usefulness.

Image title

Applicability: Forecasting is used in most agile methods in order to determine the likely deliverables by the end of a given timebox.

Consequences: Forecasts can be mistaken for commitments and it is important to qualify expectations accordingly. The accuracy and value of forecasts diminishes the further into the future they extend.

Implementation: Scrum development teams generally limit their forecasts to end-of-Sprint deliverables. The Sprint Backlog and Sprint Goal effectively represent their forecast, and will depend on estimates. Kanban forecasting does not necessarily use estimation at all. For small and repeatable changes, forecasts based on backlog position and throughput are possible.

Further reading:

Scrum Myth: The Sprint Backlog is a Commitment 

Commitment Considered Harmful

Scrum: The Obsession With Commitment Matching Velocity

scrum Sprint (software development) agile

Opinions expressed by DZone contributors are their own.

Related

  • Non-Traditional Project Planning
  • Sprint Goals: How to Write, Manage, and Achieve
  • Compatibility Testing: Checklists and Crucial Things You Need to Know About It
  • Conducting Sprint Retrospective Meetings

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: