I was teaching a class just a few weeks ago. It was focused on agile basics, user story writing & backlogs, sprint planning and all of the basic operations to kick-off a set of Scrum teams. It was going quite well on the first day and I was fielding the myriad of questions that typically come your way in an initial class of this sort.
Then I got hit with a question that I struggled to effectively communicate a succinct and direct answer to. The question was simple on the surface:
If within a sprint the team can’t seem to get the work they planned done, don’t you simply put it back on the backlog for execution in the next sprint?
I muddled around for a bit trying to answer the question. I merged my answer with the notion of sprint failure and success. I also spoke about team commitment. Both topics I’ve recently blogged about
But I could tell the questioner was frustrated with my answer—that they simply wanted me to say yes. Yes, just slide it onto the backlog. And that certainly would have been the easier way out for me.
So, we left it that they were frustrated and I moved on. But I’ve been thinking about this since then, and I thought it would be helpful to answer the question in this blog post. Or at least discuss more of the nuance behind my broad and feeble attempt at answering it.
Let’s First Go To Commitment
The first part of my struggle surrounds the teams’ commitment of delivery towards the sprint goal. Please reference my previous post for much more background here. But the essence is—the team committed to delivering a body of work supporting their sprint goal and I want them to well...deliver on their promise! I don’t want it to be easy for a team to defer work out of the sprint. I don’t want them to whine about missed estimates or technical complexity. I don’t want them to get accustomed to breaking their promises. I want them to seriously plan, seriously commit, and then seriously deliver on their sprint goals. Period!
If they do encounter “unexpected turbulence”, then I want them to think really hard about how they might be able to adjust to the new found work. Think creatively and leverage the ideas of every team member. If they need to make in-the-sprint adjustments, they need to pull the Product Owner into the conversations. As they explore options & alternatives, they should put their commitment and the sprint goal front and center.
Turbulence, I mean Discovery Happens…A Lot!
And we need to remember that “s**t” happens within Scrum sprints…all of the time! The teams often find that they:
- Underestimated the work
- Overestimated the work
- Didn’t account for technical complexity
- Didn’t truly understand the customers problem
- Didn’t account for someone taking vacation
- Or getting sick
- Didn’t fully understand the stories
- Didn’t groom properly
- Don’t have the requisite skills or knowledge to do the work
- Didn’t account for testing complexity
- Didn’t capture the right acceptance tests
and this list isn’t exhaustive. Things come up every day within sprints, which is why I don’t want deferring work to be the automatic or default reaction. This sort of “get out of jail free” card isn’t the intent of agile nor does it align with the commitment they’ve made to their Product Owner and themselves to deliver on the sprint goal.
Now can they move work to the backlog? Sure, absolutely, you bet! But determining whether they should actually take that road is an entirely different question.
Another Assumption
Another implication of the question is that if something slips out of the sprint that it simply & easily goes to the top of the backlog for execution within the next sprint. But that’s not always true. Once something re-enters the backlog, the Product Owner has the responsibility to reprioritize it, but it’s their decision as to how to handle the ordering. And it may not be as simple as…reprioritize to #1.
For stories that are focused on features to be delivered, then the Product Owner may have made commitments to external customers that are difficult to break or re-frame. The other factor is that there may be embedded time constraints as part of the story—meaning it needs to be delivered by a specific date.
What about the teams’ quality values? Should done-ness be easily violated in these cases? Here’s an example to illustrate a point surrounding done-ness.
Example
A team has done-ness criteria established for story delivery. It states that a story will be delivered with no known bugs i.e., they’ll be fixed prior to story completion and acceptance.
So, the team is working on a two-week sprint. The #2 priority story is predicted to take nearly the entire sprint to complete in sprint planning. The good news is that the team was right on this one. It’s day #8 and the story is nearly complete. The code is complete and multiple rounds of testing have been done. The team is feeling really good about the story and demonstrates it to their Product Owner for acceptance.
The bad news is that there are 13 known bugs related to the story. They’ve fixed 4 of them, but they can’t complete the other 9 by the end of the sprint. And even more telling, they uncovered a refactoring effort that needs to be completed as part of re-designing the codebase to support the story. So they essentially hacked the story into existence and are recommending a 15 point refactoring story to “do it right” in the very next sprint.
The team feels they completed the story and due to “extenuating circumstances” on day #8 they let everyone know that 9 bugs and 15 points of refactoring need to be completed before this story is ultimately finished.
I have a few questions for you:
If you’re the Product Owner, how do you prioritize this new/additional work? How do you balance it against your pre-existing release plans?
From the teams’ perspective, did they really finish the story? If not, what should have occurred within the sprint to potentially deliver a more complete story—pun intended?
How would you react or feel if I said the team should have ‘swarmed’ around getting this story completed—no matter what?
And finally, should this sprint be considered a success or a failure?
I’m hopeful these questions generate some healthy comments…
Micro Adjustments & The Product Owner
The above example leads into a related idea. I’ve been using the term “micro-adjustments” a lot lately to illustrate the dynamic between the Product Owner and the Team during sprint execution. The notion is that the sprint goal serves as a measuring stick that the team can use continuously throughout the sprint to guide their minor scope adjustments and trade-offs.
And believe me—adjustments are certainly required. Actually, not required—they’re a fundamental part of the lean nature of scrum.
So instead of adjusting whole stories in or out of a sprint, I think the healthier view is for the team to engage the Product Owner as early as possible as discoveries are made within each sprint. For each potential adjustment, the PO and team examine the issue through the lens of holding the sprint goal intact. So every trade-off is relative to the goal.
If the team can hold the goal by reducing the scope of a feature, then so be it. Then it’s up to the PO to determine if that scope trade-off needs to result in an additional story to the backlog or not. But I don’t want there to always be a story produced. In many cases, micro-adjustments will result in “good enough” software being delivered at the end of the sprint, with the resulting trade-offs never needing to enter the backlog. In fact, they were never needed in the first place.
So the other nuance I was trying to address in fumbling my answer was this notion of micro-adjustments and not falling into the trap of looking at stories as fixed in scope. Instead, the entire sprint is an emergent exercise that is guided by the sprint goal.
My overall experience in sprints is that very little needs to exit the sprint and re-enter the backlog. Sure, there is the occasional bug or refactoring story. And yes, stories do occasionally “pop out” onto the backlog. But the majority of the time, the scope trade-offs are internalized and adjustments made that don’t ultimately impact the backlog.
Indeed, more often is the case where the team PULLS WORK from the backlog into the sprint because they’ve discovered more capacity versus the scope they’d planned on delivering. Now that’s agile!
Wrapping Up—so what is the answer?
To use my standard consulting answer with tongue firmly in cheek—it depends.
In fact there are no universal answers to the question. Sometimes it’s a perfectly healthy and balanced response to push work from within a sprint to the product backlog. It makes sense and the overall agile integrity of the team is not compromised.
But in many other cases, this get out of jail free card can have some bad side-effects. It puts the sprints success in jeopardy. It can undermine the teams’ commitment to results. And it can place the Product Owner in a precarious position. It also usually implies that the team isn’t operating with a full “agile mindset” within their sprints.
I would always rather that the team viewed “punting work” outside of the sprint as a last resort—one that they carefully consider and leverage infrequently.
Now if I only had a second chance to answer that students question…
Thanks for listening,
Bob.