www.scrum.org Open in urlscan Pro
34.233.202.171  Public Scan

Form analysis
2 forms found in the DOM

GET /search/node

<form action="/search/node" method="get" id="search-block-form" accept-charset="UTF-8" data-once="form-updated" data-drupal-form-fields="edit-keys">
  <div class="form-item form-group form-type-search form-item-keys form-no-label">
    <input title="Enter the terms you wish to search for." data-drupal-selector="edit-keys" type="search" id="edit-keys" name="keys" value="" size="20" maxlength="128" placeholder="Search" class="form-search form-type- form-control">
  </div>
  <div data-drupal-selector="edit-actions" class="form-actions js-form-wrapper form-wrapper" id="edit-actions">
    <input data-drupal-selector="edit-submit" type="submit" id="edit-submit" value="Search" class="button js-form-submit form-submit form-type- form-control">
  </div>
</form>

POST /resources/blog/commitments-and-forecasts-when-using-scrum?destination=/resources/blog/commitments-and-forecasts-when-using-scrum

<form class="user-login-form" data-drupal-selector="user-login-form" action="/resources/blog/commitments-and-forecasts-when-using-scrum?destination=/resources/blog/commitments-and-forecasts-when-using-scrum" method="post" id="user-login-form"
  accept-charset="UTF-8" data-once="form-updated" data-drupal-form-fields="edit-name,edit-pass,edit-submit--2">
  <div class="form-item form-group form-type-textfield form-item-name">
    <label for="edit-name" class="js-form-required form-required">Email address</label>
    <input autocorrect="none" autocapitalize="none" spellcheck="false" data-drupal-selector="edit-name" type="text" id="edit-name" name="name" value="" size="15" maxlength="60" placeholder="email address"
      class="form-text required form-type- form-control" required="required" aria-required="true">
  </div>
  <div class="form-item form-group form-type-password form-item-pass">
    <label for="edit-pass" class="js-form-required form-required">Password</label>
    <input data-drupal-selector="edit-pass" type="password" id="edit-pass" name="pass" size="15" maxlength="128" placeholder="password" class="form-text required form-type- form-control" required="required" aria-required="true">
  </div>
  <input autocomplete="off" data-drupal-selector="form-i-bbnkrvmh3foa-udeb5ulnygxtveil4zp2zj7c6lfo" type="hidden" name="form_build_id" value="form-i-bbnKRVmH3FOa_uDEB5uLNYgxtveiL4ZP2zJ7C6lfo" class="form-type- form-control">
  <input data-drupal-selector="edit-user-login-form" type="hidden" name="form_id" value="user_login_form" class="form-type- form-control">
  <div data-drupal-selector="edit-actions" class="form-actions js-form-wrapper form-wrapper" id="edit-actions--2">
    <input data-drupal-selector="edit-submit" type="submit" id="edit-submit--2" name="op" value="Go" class="button js-form-submit form-submit form-type- form-control">
  </div>
</form>

Text Content

Skip to main content
Home
X
 * login
 * register
 * partners
 * support
 * Search

 * Home
 * About
   * Back
   * About
   * Who is Scrum.org
   * Why Scrum.org
   * Partners
   * News
   * Staff
   * Professional Scrum Trainers
   * Diversity & Social Responsibility
   * Careers
   * Support Center
   * What is Scrum?
   * Professional Scrum Defined
 * Training
   * Back
   * Training
   * All Courses
   * Class Schedule
   * Applying Scrum
   * Scrum Master
   * Advanced Scrum Master
   * Product Owner
   * Advanced Product Owner
   * Agile Leadership
   * Evidence-Based Management
   * Scaled Scrum
   * Scrum with Kanban
   * Scrum with User Experience
   * Developer for Software Development
   * Request a Private Class
   * Find a Trainer or Coach
   * Students Reviews
 * Certification
   * Back
   * Certification
   * All Certifications
   * Professional Scrum Master
   * Professional Scrum Product Owner
   * Professional Scrum Developer
   * Professional Agile Leadership
   * Professional Agile Leadership - Evidence-Based Management
   * Scaled Professional Scrum
   * Professional Scrum with Kanban
   * Professional Scrum with User Experience
   * All Practice Tests
   * Scrum Open
   * Product Owner Open
   * Scrum Developer Open
   * Agile Leadership Open
   * Evidence-Based Management Open
   * Nexus Open
   * Scrum with Kanban Open
 * Community
   * Back
   * Community
   * Blog
   * Forum
   * Meetups
   * Events
   * Become a Professional Scrum Trainer
   * Register for our Newsletter
   * Search Professional Scrum Certificate Holders
 * Innovations
   * Back
   * Innovations
   * Scaling Scrum with Nexus
   * Evidence Based Management (EBM)
   * Scrum with Kanban
 * Resources
   * Back
   * Resources
   * All Resources
   * Professional Scrum Competencies
   * The Scrum Guide
   * Webcasts
   * Videos
   * Case Studies
   * Books
   * Scrum Masters Learning Path
   * Product Owners Learning Path
   * Software Developers Learning Path
   * Agile Leader Learning Path



X
Back
X


LOGIN

Email address
Password

 * Forgot Password


NOT REGISTERED?

If you don't already have a Scrum.org account, you can sign up in just a few
seconds.

Register Here

Due to the Russian invasion of Ukraine, we have paused all purchases and
training in and from Russia.  Read Statement

Subscribe to our blog by signing up for the Scrum.org newsletter, or by
subscribing to the RSS feed.

 RSS
Back to Blog Listing Prev Next
July 20, 2022


COMMITMENTS AND FORECASTS WHEN USING SCRUM

Paul Ralton

Paul Ralton website Paul Ralton LinkedIn Paul Ralton contact View profile


4.8 from 3 ratings
0 Comments

A regular topic of conversation within my Scrum training courses revolves around
commitments and forecasts when using the Scrum framework. Frequently we uncover
significant and important misunderstandings about what Scrum Teams can commit to
and what they cannot.

The most often talked about example refers to those Product Backlog Items which
are taken into a sprint by the developers and which then seems to turn into a
hard commitment such that if not all those Product Backlog Items are done then
something is wrong and a possible belief that the Scrum Team has failed.

This article is an attempt to help debunk at least this one myth whilst using
the Scrum framework to build complex products and an overall recap around
commitments versus forecasts in general across some of the evolutions of the
Scrum Guide over time.

 


LET'S BE CLEAR ON WHAT COMMITMENT ACTUALLY MEANS:

A quick online search gives these two definitions for 'commitment':

 * "The state or quality of being dedicated to a cause, activity"
 * "An engagement or obligation that restricts freedom of action"

These are actually quite different in meaning. The first relates to dedication.
"I couldn't fault the team for their commitment". The second relates to a future
state that we are promising to achieve, a guarantee, a promise.

Let's now explore some of the key elements around commitments and forecasts from
the Scrum Guide as it has evolved over time.


SCRUM GUIDE 2010

 * "The Team has committed to a Sprint Goal, and to these Product Backlog items"

Within this first version of the Scrum Guide there is reference to the fact that
there is a firm commitment that all items taken into a Sprint are to be done. If
not all items selected are done by the end of the Sprint then maybe there has
been some kind of issue worth exploring further. Have we therefore failed as a
team since we did not achieve all that we promised?

A potentially interesting point around this is the fact that probably a lot of
teams currently using Scrum today have never read this original 2010 version but
yet still have a strong belief that all items selected must be done or else
something has gone wrong. If this has not come about from reading this version
then could it be due to the culture and behaviours already inherent within the
wider organisation?



SCRUM GUIDE 2011

Thankfully this use of commitment did not stay long and was updated in 2011.

 * "...the Development Team forecasts the Product Backlog items it will deliver
   in the Sprint" 
 * "...Development Team to forecast what it believes it can do in the upcoming
   Sprint" 
 * "...Commit is now forecast"

Early on there was a realisation that when dealing with complexity and
significant amounts of unknowns that it is simply not possible to perfectly plan
all that is to be done even within the time-box of just one Sprint.
 


SCRUM GUIDE 2016

The 2016 version introduced us to the Scrum Values and one of these is
commitment.

In this regard it means (but not limited to) committing to being professional,
committing to quality, committing to helping and supporting each other,
committing to working on tough problems, committing to our goals. This touches
on both meanings around commitment. Both on the dedication and effort
perspective whilst also hooked into the promise of focussing on delivering
future goals.
 


SCRUM GUIDE 2020

The 3 commitments were then added in 2020.

Each of the core 3 artefacts now has a corresponding commitment which all help
bring transparency to the artefact they are a commitment for - so for the
Increment we have the Definition of Done, for the Product Backlog we have the
Product Goal and for the Sprint Backlog we have the Sprint Goal.

Developers adhere to the Definition of Done.....that's completely
non-negotiable. That's a firm commitment. A promise.

The Product Goal and Sprint Goal help Scrum Teams focus on current progress
towards a future state which serves empiricism. A Scrum Team is committed to
working on one Product Goal at a single point in time and either achieving or
abandoning that Product Goal before then moving to the next one.

The Sprint Goal is created by the whole Scrum Team during Sprint Planning (note
- the whole Scrum Team and not just the Product Owner). The developers are then
committing themselves to creating at least one usable increment by the end of
each Sprint that achieves that single Sprint Goal. This is their commitment.
They are not committing to completing all the Product Backlog Items taken into a
Sprint. As the Sprint progresses and as more is learnt about this work then so
the Sprint Backlog is emergent. There has to be a level of flexibility that the
Sprint Goal provides. The Scrum Guide makes this super clear:

 * "...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 is the outcome we are after achieving....the Product Backlog
Items selected to achieve that Sprint Goal forms the output. Scrum Teams should
always look to maximise outcomes and minimise output. The Sprint Goal is their
commitment.....the selected items are their forecast.



IN SUMMARY...

Be clear what you commit to and what instead must be a forecast due to the
inherent nature around complex product delivery.

Commit to goals. Commit to doing the best you can at all times. Commit to
helping those around you. Commit to building products of the highest quality.
Commit to the Definition of Done.

Remember that Product Backlog Items taken into a Sprint are very much a forecast
and not a commitment. Forecast longer term plans with the expectation that these
will continue to change and evolve as more insights emerge over time.

Ultimately understand and be professional around what you can and cannot make
commitments against.

Want to learn more and talk further about commitments and forecasts,
professional Scrum or indeed any element of the Scrum Framework? Check out our
upcoming courses on our course schedule with b-agile. We offer both public and
private courses to fit your needs.


SHARE THIS POST

 * Email
 * Facebook
 * Twitter
 * LinkedIn
 * Reddit
 * Pocket

Blog Comments

Prev Next
By using this site you are agreeing to the Privacy Policy and Terms of Service X

© 2022 

Scrum.org. All Rights Reserved.
 * Contact
 * Privacy
 * Terms of Service
 * TM and © Guidelines

 * https://twitter.com/Scrumdotorg
 * http://facebook.com/scrum.org
 * https://www.linkedin.com/company/scrum-org
 * https://www.youtube.com/user/Scrumorg