It happens to every team. The sprint is coming to an end and the team has nothing to demo. Is it because no progress was actually made? Unlikely. Usually, it’s because the progress isn’t something that can be easily shown. In this situation, most teams want to skip the demo. You can’t blame them really. The team is likely embarrassed and almost certainly frustrated. They worked hard but don’t feel as if they have anything to show for it.
In reality, there was progress made and lessons learned. The team’s concern is that the progress wasn’t what was expected. They may fear the feedback they’ll receive if they present what they have. More commonly they may feel the audience for the demo doesn’t care about progress they can’t easily see.
Many agile frameworks and methodologies are rooted in empiricism, a theory stating knowledge comes from experience. This is part of why short feedback loops are so prevalent in agile circles.
One of the pillars of an empirical process is transparency. Sometimes this is brought in as a value to the framework, sometimes as a benefit of the process, and even occasionally as a side effect. Whatever form it takes, the review is one of the places transparency is delivered.
I believe part of the problem may be a belief that only items that fit the definition of done should be brought to the sprint review. I would agree that only completed items should be given a demo, but the sprint review is more than just a demo of completed functionality. Just as a retrospective is a chance for the team to calibrate their work, the review is a chance for the stakeholders outside of the team to help calibrate the product direction. This meeting involves more than just seeing a demonstration of the increment the Product Owner intends to accept. This is a chance for the development team to see people interact with the product in real-time, a chance for the end-users to guide the future direction of the product by giving immediate feedback, and a chance for the Product Owner to learn how the backlog should change going into the next sprint. This review is part of the rapid feedback loop and should be treated as such.
There is a balance to strike here. Any work done which provides new insight or drastically changes estimates on stories is worth presenting for discussion in some form. Another idea is to show partially completed items, in a presentation format, not a demonstration, and gather direct feedback. Big decisions that could have ramifications on future work should also be brought up here. It might be useful to mention any training taken, but going over what was learned in that training probably isn’t. Small decisions made by dev team members, using an integer versus a big integer for instance, probably don’t belong here either.
Getting the team and organization to reframe their idea of what the review is for will make it a much more powerful event. When the review is about gathering feedback on the present and future state of the product then roadblocks and problems become valuable to share in that format. With the meeting turning into a collaborative feedback session the team should no longer fear showing incomplete items and discussing why. The entire stakeholder team can then provide feedback on what should be done, and the Product Owner can move to the next sprint with a great level of confidence that the team and stakeholders are aligned.
In addition to feedback, having the review work a session to go over both completed items and incomplete items increases the team’s transparency. Instead of just leaving a feature that got dropped from the sprint out a discussion on why it was dropped can happen which lets the Product Owner make an informed decision on whether to bring it back in or not. It’s entirely possible once the stakeholder pool finds out a user story has tripled in size they’re going to want to drop it down the priority list. These are some of the true outcomes you should strive for in your review.
Having shifted your team’s view of the review meeting they are not likely to want to skip it anymore, even if nothing managed to make it to the definition of done.
If your organization could use some help with their agile implementation please contact me here. We’ll have a chat and see if it makes sense for us to work together or not.
More
It happens to every team. The sprint is coming to an end and the team has nothing to demo. Is it because no progress was actually made? Unlikely. Usually, it’s because the progress isn’t something that can be easily shown. In this situation, most teams want to skip the demo. You can’t blame them really. The team is likely embarrassed and almost certainly frustrated. They worked hard but don’t feel as if they have anything to show for it.
