Only Show Finished Work During a Sprint Review—Maybe

I was at dinner years ago with my wife, a friend, and his girlfriend. After the main course, our waiter brought around a dessert tray. As he pointed out each dessert option, the waiter made a show of flicking his finger into the item he was discussing. Fortunately, the items were all plastic and his finger bounced off the fake dessert without harming it.

"I'll have the key lime pie," I said. My wife chose the creme brulee. Wanting to have a little fun, my friend Allan didn't say which he wanted. Instead he flicked his finger into what he thought was a fake slice of chocolate cake. Surprisingly, it was not a fake slice of cake and Allan's finger was embedded halfway into a real slice of cake. The cake was the only item on the dessert tray that was real. We hadn't noticed that it was the only item our waiter had not himself flicked.

This wouldn't have happened if our waiter hadn't mixed up a real dessert with a bunch of fake desserts.

Why Scrum Teams Show Completed Work During Sprint Reviews

This same problem shows up on during a sprint review if scrum teams mix work that is done and work that only appears to be done.

The Scrum rule is that during a sprint review a team is allowed to demonstrate only those product backlog items that are truly done. They can't demonstrate a screen without its backend coded, for example.

In general, this is a great rule. It prevents a team from showing a plate of ready-to-eat, real desserts mixed with a few fake desserts that look good but aren't really available.

If a team is allowed to show work that is nearly, but not fully, complete there is the risk that the team starts to do this more and more often because it feels good to show all that progress. But extrapolate that forward a few sprints and you'll see that the team will have to show more and more false progress just to appear to be going at the same speed. In effect, the lies get bigger.

There is also the huge risk that stakeholders mistakenly believe the work is done. Sometimes this is the fault of the team, which isn't clear enough in saying something is not done. Other times, though, the team may be perfectly clear, but stakeholders don't hear the message. Many years ago when big prototypes were more common, the term "protoduction" came into use to refer to a prototype that was forced into production use.

Can Teams Ever Show Unfinished Work During Sprint Reviews?

But are there times when it might be OK for a team to violate this Scrum rule and show a product backlog item that is not done?

Yes, I think there are times when it is OK to do.

Keep in mind that the purpose of a sprint review is to get feedback that can be used to inform what should be done next. To do that, it may sometimes be helpful to show work that isn't 100% done. And a sprint review can be a great forum for doing that because of the audience that may be there. For example, you may have everyone you need to comment on whether the visual design of this next item meets everyone's expectations. So go ahead, show that feature and get feedback on it.

So, while I'm not advocating the violent overthrow of the Scrum rule of only demonstrating what is finished, I do think it is worth understanding why that rule is in place: It prevents teams from deceiving themselves into thinking they are further along than they are, and it prevents teams from deceiving their stakeholders (intentionally or not).

But, don't let the rule prevent your team from getting valuable feedback on something that isn't quite yet done if that feedback would be hard to get another way.

How to Know If It's OK to Go Against the Scrum Guide

A few simple guidelines can help you make sure your team is only breaking this rule when doing so is appropriate. I do not recommend breaking this rule:

• when first starting with Scrum
• when there is any chance the work will be misconstrued as being truly done
• when the feedback you'd get could be easily gotten another way

If you follow those guidelines, you'll stay true to the intent of the rule and, unlike that long-ago waiter, won't cause your customers to stick a finger into perfectly fine piece of chocolate cake.