Updated content and language on August 26, 2021
A successful Scrum team is responsible for not just the quality of their work, but also the quality and professionalism in how they DO their work. In this article, we will discuss how a team bears responsibility for the Sprint and what they should do if they discover they can’t get everything done that they committed.
If you want to build a successful Scrum team that routinely delivers what they say they will, there are a number of practices that will be key to your success. We talk about many of those on this website, including working on small backlog items, limiting your work in process, having team ground rules, DONEness definitions, and how to do effective Sprint Planning. If you can get your team engaged in all these practices, you will be well on your way to creating a high performing team. Another practice that will help your team to become more and more predictable may seem simple and quite obvious, but is often overlooked by teams until it’s too late — keep checking against your sprint goal.
Like I said, it sounds obvious, and traditional project management methods recommend regular status meetings to verify the state of the project and head off risks and other potential wastes. Your Scrum teams can benefit from this same practice: by checking every day whether or not the team is on track to complete their goal for the Sprint, your team can take pre-emptive steps to correct any potential roadblocks to delivering what they committed.
For example, let’s assume that, during a daily Scrum, the team has determined that one of the product backlog items that is in progress is running seriously behind. Some teams just leave it at that; when the daily Scrum is over, they all go back to work! What’s the point of that? If a daily Scrum unearths the reality that the team might not achieve the goal for the Sprint, shouldn’t they do something about it?
Well, yes, of course!
So, let’s suppose that the team in question, having learned during the daily Scrum that they might not achieve the goal for the Sprint, finishes the daily Scrum and then begins a discussion as to why. Why aren’t we going to achieve the goal for the Sprint? What changed? We, the team, committed the work during the Sprint. Is the situation we’re in something out of our control? In the Scrum Patterns website, Jeff Sutherland (the creator of Scrum) suggests the following steps when the team determines they might have a problem:
- Change the way work is done. Do something different.
- Get help, usually by offloading backlog to someone else.
- Reduce scope.
- Abort the Sprint and replan.
- Inform management how release dates will be affected.
“Changing the way work is done” leaves a lot to the imagination. Are the right people working on the right tasks together? Often, when we try to do some cross-training, we lose productivity for learning time. Maybe we shouldn’t do that this Sprint. Are we using a tool that is taking too long (often trying to “do it right” means taking a lot of time to do something when there really isn’t a lot of value in the extra effort). Was there a more expedient solution (maybe not the “best” one, but one that would work and cost a tenth of the time)?
“Get help, usually by offloading backlog to someone else” means just what it says. If your team can’t everything done, is there a way to move work to another team or is there a way to get someone to temporarily help the team. I’ve seen both done. Working on a large project in Germany, there were teams that found themselves behind and the ScrumMasters would work together to find a way to redistribute the backlog items to allow everyone to get done. When I worked for a large multi-national, my mentor suggested that all Scrum teams should always strive to be right on the edge of being able to finish everything committed. If a team got behind, a team that was ahead would automatically come to their rescue and balance the workload. My mentor even suggested using traffic lights for every team room. Teams that were ahead would be “green,” teams behind were “red,” and teams on the edge were “yellow.” Green teams would come to the aid of the red teams and attempt to get everyone to yellow.
“Reduce scope” is pretty clear. This is what the Scrum framework suggests out of the box. Jettison backlog items from the Sprint Backlog back to the Product Backlog. And don’t wait until the end of the Sprint to do it. Do it now! Keeping the workload achievable is what helps teams learn to do better.
“Abort the Sprint and replan” if there’s just no way to fix the Sprint, it’s pretty fouled up. Remember “fail fast?” Rather than waste more time fixing a sinking boat, jump off and get yourself a new boat. Terminate the Sprint and plan a new one.
“Inform management how release dates will be affected” means to ensure that management is aware of the impact of any changes that you may have made that might affect the release dates (if there is any affect). Always keep management informed of what’s going on and why. Keeping management in the dark never works out well in the end.
Remember, bottom line, the DEVELOPERS ARE RESPONSIBLE for the success of the Sprint Goal. Not management. If the Sprint is in trouble, it is up to the team to fix it. Always keep your eyes on the goal!
More About #Sprints
What is a Sprint Demo? #AskArtisan
What's a Sprint Demo? It's typically a sure sign that your organization has no idea how to do a Sprint Review! I'll explain in this edition of #AskArtisan.
How do you Plan for Support Time in a Sprint? #AskArtisan
Many Scrum Teams ask how to plan for support work in a Sprint. Can you plan the unplanned? There's no simple answer, but there IS an answer!
Can One Sprint Have Multiple Goals? #AskArtisan
Can you have more than one Sprint Goal in a single Sprint? I actually recommend it! In this video, I'll explain how it can improve Scrum team productivity.
How Are Product Goals and Sprint Goals Related? #AskArtisan
I'm often asked about Scrum goals; specifically Sprint Goals, Product Goals, and how they relate to each other. In this video, I'll tie them together for you.
What’s a Sprint Goal? #AskArtisan
Ever been out shopping only to get home and realized you didn't actually get what you needed? This is what happens to Scrum teams without a Sprint Goal!
What Do You Do With Incomplete Work at the End of the Sprint? #AskArtisan
One of the questions I get asked a lot has to do with when a Sprint ends… what happens with all the work that isn’t finished at the end of the Sprint?
What is Scrum?
The most popular Agile Development framework, Scrum, can be explained in many ways. If you're just trying to understand what Scrum is, this post is for you.
Gearing a Team for Maximum Outcomes
Creating a maximum outcome team is every ScrumMaster’s goal, but you must first understand how great teams form and what YOU need to do to create a great team.
Jim’s 10 Tips for Scrum Development Teams
With COVID-19 forcing us all to learn about working from home, we're re-publishing our list of "Jim's 10 Tips for Scrum Development Teams," UPDATED for 2020!
Leave A Comment