Viewing entries tagged
carryover stories

When Sprints End Badly


When Sprints End Badly

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.