Of course it’s going to happen. No matter how good an agile team is, eventually they’ll have a tough sprint and something bad will happen. They’ll miss the work they committed to in the sprint and some of it will need to carryover to the next sprint.

Mike Cohn had this to say about demonstrating that work in the current sprint in his December 10, 2015 newsletter:

A standard rule in sprint reviews is that the team should show only work that has been completed. This rule prevents a team from feeling that they’ve made more progress than they really have. Additionally, it avoids any risk that attendees leave a review confused about what has really been completed.

And so, teams are told they cannot show slides or partially finished work.

This is a great rule. But, just like my daughter tells me about her curfew, some rules are meant to be broken.

And so I sometimes break the rule about only showing finished work. A sprint review often brings together important stakeholders who are rarely together otherwise. That is a wonderful opportunity to ask them collectively, “What do you think of this screen [or other work] that is in process?”

It would be a shame to forego this opportunity just because of a Scrum rule.

Mike echoed my own advice for teams. But I usually adopt a harsher, no review posture, and Mike’s newsletter forced me to reconsider that advice.

I want to explore several aspects of sprint work that weren’t all covered in his newsletter.

Carry Over Work

A related topic to this discussion is how to handle work that “carried over” to the next sprint.

• How is it handled? For example, what is the impact to sprint tracking, metrics, and velocity?
• How much is allowed? And is it the “norm”? And should/how do we make it transparent?
• And if the organization & teams agree that it’s “Bad”, what is everyone doing about it?

In this article, I explore more details in this work –

Showing “incomplete work” at the review?

I think I’ve been a bit too binary in my advice to-date. That is, if you have work that is less than 100% complete, you don’t “show it” in the review.

I now want to lighten up a bit…thanks Mike!

I think the team (with the strong engagement / involvement of the Product Owner) can decide to show anything they worked on in the sprint. The focus should be on gaining valuable feedback.

But the focus should also be on clearly communicating to the “audience” that the work is NOT DONE. Just so nobody leaves the demo and immediately sells the feature to multiple clients.

Have you failed?

I also like for the team to take the stance that they failed to meet their plan and commitment for the sprint. In other words, admitting clearly that they failed.

• I don’t want them to feel sad, despondent, guilty, or bad in any way. But I do think this level of honest transparency goes a long way.
• It clearly communicates to the audience that they missed their goals.
• It clearly communicates to the team that they have some work to do in their retrospective.
• But beyond all of that, there is a sense of congruent honesty that the team emanates that I believe underlies a healthy team and organizational culture.

This article explores the notion of “failure” in more detail –

Wrapping Up

I actually think that a sprint ending badly is a good thing. It’s an opportunity for the team to learn from their mistakes and improve.

In fact, I really like the occasional failure. It:

• Makes for a juicy retrospective, that is lively and focused towards something concrete to improve;
• It keeps your stakeholders engaged – not thinking that software development is always smooth and easy;
• It grounds everyone back to the Real World, where Sh*t does happen;
• And it makes the upcoming successes all the sweeter as each teams continues to learn, evolve, and grow in their agile journeys.

So pick yourself up, dust yourself off, and get excited about what’s next.

Stay agile my friends,

Bob.