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/how-refine-your-improvements-actionable-quick-tips?destination=/resources/blog/how-refine-your-improvements-actionable-quick-tips

<form class="user-login-form" data-drupal-selector="user-login-form" action="/resources/blog/how-refine-your-improvements-actionable-quick-tips?destination=/resources/blog/how-refine-your-improvements-actionable-quick-tips" 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
June 28, 2022


HOW TO REFINE YOUR IMPROVEMENTS INTO ACTIONABLE QUICK TIPS?

Barry Overeem

Barry Overeem website Barry Overeem Twitter Barry Overeem LinkedIn Barry Overeem
contact View profile


5 from 1 rating
0 Comments

> “Next Sprint, we’ll start releasing sooner and more often”

> “From now on, we’ll improve how we collaborate with our stakeholders”

> “Let’s expand the Definition of Done to improve quality”

> “To minimize dependencies, we’ll try to become more cross-functional as a
> team”

> “Let’s try to use a Product Goal and Sprint Goals to give our team more focus”

These are five examples of common improvements made by Scrum teams. Improvements
I’ve experienced myself in my work with Scrum teams, or ones that I’ve heard
during our training, workshops, and meetups. The intention of these improvements
is great and makes sense. I can only encourage teams to improve in these areas.

There’s only one problem. With improvements like this, it will probably remain
with good intentions only. They are way too vague, abstract, or comprehensive.
It’s not clear who’s going to do what, when, why, or how. Even when this is
clear, the improvement is too large to finish the next Sprint, which makes it
difficult to determine if you’re heading in the right direction. As a result,
Scrum teams struggle to start their engine for continuous improvement. Instead
of going through the motion of “transparency, inspection, and adaptation”, Scrum
teams can’t adapt because the improvements aren’t feasible.

One of the reasons this happens is that Scrum teams do refine their Product
Backlog, but they don’t refine their improvements. This is surprising because
improvements should be considered as “work” as well. Work that’s part of your
Product- and Sprint Backlog.

In this blog post, we explain the purpose of Product Backlog refinement and
share examples of how to refine improvements. We also show how the (free) Scrum
Team Survey contains refined quick tips to support Scrum teams with continuous
improvement. Give it try if your team struggles with identifying small and
specific improvements!



Instead of going through the motion of “transparency, inspection, and
adaptation”, many Scrum teams can’t adapt because the improvements aren’t
feasible. They are too vague, large, or abstract to implement.


PRODUCT BACKLOG REFINEMENT

As we describe in our Scrum paper, Product Backlog refinement exists, first and
foremost, to break down large chunks of work into smaller chunks of work. As
with everything in the Scrum framework, this makes it easier to work
empirically. If we would work on large items — that take weeks or even months to
complete end-to-end — we would be unable to get frequent feedback from our
actual stakeholders. This introduces the significant risk that we make incorrect
assumptions about what stakeholders need that, once falsified, require us to go
back and change everything.

So instead our aim with Scrum is to more frequently deliver smaller chunks of
work so that our stakeholders can give us meaningful feedback that spurs new
ideas, changes to what has already been done, or uncovers bugs that need to be
addressed. In short, delivering small bits of work is a great way to help us
think and understand what is needed.

All the work on your Product Backlog should eventually be refined to make it
small enough — but only when you’re about to start work on it in a coming
Sprint. When something is “small enough” depends very much on your context. But
as a starting point, your team should refine to a degree where they can
comfortably select and complete multiple items in a single Sprint. Experienced
Scrum teams will tell you that smaller is generally even better.



Product Backlog refinement exists to break down large chunks of work into
smaller chunks of work. This is a great way to help teams understand what is
needed, and validate assumptions early and often.

For exactly the same reasons, Scrum teams should refine their improvements into
small chunks of work. As such, they can validate if the improvement has the
desired impact and if changes are necessary. It avoids the risk of spending
weeks or even months on one large improvement, only to discover it doesn’t solve
the problem at all. This is not only a waste of time and money but will also
damage team morale.


HOW THE SCRUM TEAM SURVEY HELPS

With the Scrum Team Survey, teams can diagnose themselves with an extensive,
scientifically validated survey and receive detailed results and evidence-based
feedback upon completion. Some of the feedback consists of recommendations for
do-it-yourself workshops to run and quick tips to try. The 65 DIY
workshops allow Scrum teams to create transparency around the state of Scrum,
offer a step-by-step explanation to inspect the results together and give
guidance to make adaptations accordingly.

However, it can still happen that teams make that are way too large. This is why
we also created quick tips, which are based on the Liberating Structure 15%
Solutions Gareth Morgan defines these as any first step that you can take
without approval or resources from others and that is entirely within your
discretion to act. It is something that you can start right now if you want to.
It might not be the ultimate solution, but it’s definitely a good first step in
the right direction.



Trigger BIG change by starting small with ‘15% Solutions’. We call these “Quick
Tips” in the Scrum Team Survey.

Three examples of quick tips are:

 * Quick tip to improve psychological safety: During the next Sprint
   Retrospective, ask: ‘What is a conversation we currently don’t have as a
   team, but really should have?’. Next, have the conversation!
 * Quick tip to improve self-management: Pick one aspect of your current work
   method that is holding you back as a team. Stop doing it for a Sprint.
   Reflect during the Sprint Retrospective on what improved and what got worse.
 * Quick tip to improve management support: Take 10 minutes after your next
   Daily Scrum and ask ‘How can we tell if management is supporting us in the
   right areas? What else would be needed?’. Work together to identify 1
   improvement.

The purpose of these quick tips is to spark small and incremental change in your
Scrum team. Small steps in the right direction to remove impediments, improve
collaboration, manage risk, and deliver value sooner.


HOW TO CREATE YOUR OWN QUICK TIPS?

A good quick tip is short & concise, actionable & specific, bold & courageous,
and easy to use & try. Now let’s take a look again at the 5 improvements I
shared at the start of this blog post. And let’s see how we can refine them in
such a way it meets all the criteria!


EXAMPLE 1:

> “Next Sprint, we’ll start releasing sooner and more often”

More refined improvements would be:

 * “Involve at least 2 people from your supporting organization to identify and
   remove 1 bottleneck to releasing automation in your team by the end of next
   Sprint.”
 * “Visit a team that has automated something you haven’t yet, and take 1 idea
   from them that you will implement next Sprint as well.”
 * “Pledge to release at least 2 times this Sprint. Treat this as a constraint
   to spur creativity. Before you start with an item, think about how to release
   it individually.”


EXAMPLE 2:

> “From now on, we’ll improve how we collaborate with our stakeholders”

More refined improvements would be:

 * “Work with your Product Owner to schedule at least 2 interviews with
   stakeholders for the next Sprint. Do the interviews with 1 or 2 members of
   your team and the Product Owner.”
 * “Next Sprint, go on a field trip to a location with many users of your
   product. You can also split up and visit multiple sites. Report your findings
   to each other.”
 * “Create a (virtual) desk in your team space, and invite one of your
   stakeholders to use it for the upcoming Sprint.”


EXAMPLE 3:

> “To minimize dependencies, we’ll try to become more cross-functional as a
> team”

More refined improvements would be:

 * “In the next Sprint, agree that everyone completes at least one task they’ve
   never done before. Share experiences afterward.”
 * “During the Sprint Retrospective, identify 1 scarcely available skill that at
   least 3 team members will improve in the next Sprint.”
 * “Organize a workshop in the next Sprint, in which a team member who is
   skilled at a particular task demonstrates how they perform it and help others
   do it as well.”




EXAMPLE 4:

> “Let’s expand to Definition of Done to improve quality”

More refined improvements would be:

 * “Share your Definition of Done with 5 stakeholders during your next Sprint.
   Ask them what specific test or check they think you should add to increase
   quality.”
 * “Investigate 3 critical bugs that happened in recent Sprints, and work
   together to identify a small step forward to prevent similar bugs in the
   future. Update your Definition of Done and work agreements as needed.”
 * “Schedule a 60-minute workshop next Sprint to make sure that your Definition
   of Done captures what high-quality means to you. Anyone who cares about this
   can attend.”


EXAMPLE 5:

> “Let’s try to use a Product Goal and Sprint Goals to give our team more focus”

More refined improvements would be:

 * “As an experiment, start your next Sprint with a single goal that you’d like
   to achieve that Sprint, and then select the items from the Product Backlog
   that fit that goal.”
 * “Next Sprint, your team will politely say “No” to any non-critical request
   that comes in that doesn’t fit the Sprint Goal.”
 * “Ask your most important stakeholder what they think the goal of your next
   Sprint should be. Make it smaller if it's too broad.”

Do you see what all these quick tips have in common? All these improvements are
small & specific enough to finish in one Sprint. It is clear who does what,
when, and how. They’re not the ultimate solutions to all your problems, but they
will encourage the team to continuously make small improvements. Small steps in
the right direction. They’ll allow the team to learn what is needed, identify
the next steps, and simply boost team morale by showing change is possible!

To support Scrum teams in creating and capturing these improvements, we included
an “Actions page” in the Scrum Team Survey. The fields you need to complete to
add an action already help teams to make the specific. Teams can also mark
improvement actions as an “impediment”, indicating they need support from others
to get this done. As such, continuous improvement becomes a shared
responsibility of the team and the supporting organization.



The Scrum Team Survey gives teams the opportunity to capture improvement
actions. The fields you need to complete to add an action already help teams to
make them specific.


CLOSING

Product Backlog refinement is a common activity for many Scrum teams. Somehow,
refinement of improvements isn’t. This is surprising because improvements should
be considered as “work” as well. Work that’s part of your Product- and Sprint
Backlog. Improvements that are too large, vague, or abstract, are difficult to
implement. As a result, the team struggles to remove impediments and make
necessary improvements. This impacts team morale and sets a negative spiral in
motion. In this blog post, we showed you an alternative with actionable quick
tips. Give it a try during your next Sprint Retrospective. Identify an
improvement, and work together to make it as small, specific, and actionable as
possible!



Product Kit: Unleash Scrum In Your Organization. This new product kit contains a
card deck with 102 Quick Tips to improve your Scrum team. We categorized them
into the factors you also find in the Scrum Team Survey.


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