Should you demo incomplete stories in Sprint Reviews?

At the heart of the incremental model proposed by Scrum lies the Sprint Review. Every two weeks, teams get to showcase their progress and readjust plans. But what should you do with incomplete stories — work that is “almost done”, “90% done” or even “99% done”? Should you demo it or not?

I strongly believe that all work presented during the demo should be 100%, unequivocally, completely DONE. All items should respect the team’s current Definition of “Done”. Reporting only finished work helps teams assess and report their progress correctly, create realistic plans, work together more closely and develop discipline. I’ve summed up my points in the table below.

	Incomplete stories	Only complete stories
Progress	Unclear	Clear
Planning	Harder	Easier
Teamwork	Optional	Required
Discipline	Optional	Required

Table 1: Effects of demoing complete vs. incomplete stories

Get a clear picture of progress

Traditional reports have many shades of gray. A work item can be 0%, 5%, 20% or even 99% done. The status seems clear, but often isn’t. Teams report constant progress right until they are supposed to finish work. Then, the last percent might take as much time as the previous ninety-nine. Problems surface too late.

In agile, we don’t see so many colors. A story’s status can be “not started”, “in progress” or “done”. We only demo and track done stories. This clarifies progress and helps us detect problems earlier.

Make realistic plans

Most agile plans are based on velocity, the average team throughput for the past Sprints. But velocity only makes sense if teams are able to deliver constantly a similar amount of work. Take a look at the charts below (click to enlarge). Both represent the same total amount of work for eight Sprints. In the first case, the team takes credit for unfinished stories. Velocity seems stable, so the team are confident to use it for forecasting. They are wrong.

The chart on the right shows the same work, but this time the team didn’t demonstrate unfinished work. Even if the team produces the same amount of work in the eight sprints, it struggles to do it. The velocity fluctuates a lot. Now tell me, how comfortable would you be making plans based on this team’s velocity?

The first chart hides the team’s big variance in throughput. This is a big problem with accounting for partially done work. The team might hit their release date or it might be two months late. Only one of the above charts lets you know this.

Encourage teamwork

When it only presents done items at the Sprint Review, a team grows stronger. Why? Because it needs to collaborate more in order to finish things on time. The biggest reason for not finishing items in time is that the teams work in a mini-waterfall. The senior developers do some design, then all the developers start coding. The testers start testing items from the current Sprint only in the last day or two, so the features aren’t really verified by the time the Sprint ends.

When presenting partially done work, this isn’t a problem. The team demos the stories and the testers start the next Sprint by testing the current Sprint’s work. The team is completely desynchronized.

If a team agrees to only present finished work, it must increase collaboration between the various roles. There must be continuous feedback between designers, programmers and testers. Work starts in parallel and is chunked in small pieces that get developed and tested every 2-3 days. This way, there is no imbalance between the various roles and “dead” moments. The team is in sync.

Build discipline

The team becomes more disciplined when it presents only complete items at the Sprint Review. Agile reduces waste by eliminating status meetings, weekly reports or useless documents. But for a team to self-organize, it still needs some rules to guide its behavior. Only expert teams can get away with replacing Scrum’s few rules without collapsing into chaos. For the rest of us, maintaining the discipline of delivering only “done” stories increases trust among team members and with external stakeholders.

At first, skipping incomplete stories from the Sprint Review will feel weird and uncomfortable. Your velocity could be zero, which some people will find embarassing. You wouldn’t guess it, but that’s actually good news. The team has identified a big impediment which they need to solve in order to finish the Sprint Backlog in time. The added discipline clarifies progress, increases confidence in plans and strengthens the team.

What about you? How often do you bring incomplete stories to your demo?

Photo courtesy of hannah sheffield (Flickr)