“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.