Should you Showcase Stories that your Team do not get DONE?

My preference is for teams to not Showcase Stories that do not get DONE.

Stories are rarely nearly DONE

In several years of Scrum I’ve lost track of the amount of times that I have heard a Team say that a Story is nearly DONE or mostly DONE, almost DONE or 99% DONE or will be DONE very quickly after Showcase and then the Team still struggle with same Story for most of the next Iteration or longer.

What I tell teams is that if I hear any word prefixing the word DONE like “nearly” or “almost” that what my coaches ears really hear is the word “NOT” eg the Stories are NOT DONE.

Teams should not take credit for work that is not DONE

One of the main points of Showcase is to congratulate the Team for the hard work they have put in to getting their Stories DONE.

If a Team knows that they can Showcase NOT DONE Stories then they won’t work on the kinds of behaviours that enable them to get the maximum amount of Stories DONE in a given Iteration.

Being honest with stakeholders builds trust

It can be highly embarrassing for the Team if stakeholders see a NOT DONE Story at a Showcase and then a few weeks later they still cannot see the feature on the live site. Explaining why the team claimed something was finished when it wasn’t is a lot more difficult than admitting a Story didn’t get DONE in the first place.

The Teams reputation is not worth risking misleading stakeholders about one Story.

Having NOT DONE Stories is incredibly wasteful 

Even if a Story is “99% DONE” it still has to go through the following process to get DONE in some future iteration.

  1. The PO must prioritise the Story again
  2. The Team must review and rewrite the story removing the parts that are not required and adding any missing detail and conditions of satisfaction
  3. If the Story is much larger than originally estimate then it may need to be split
  4. The Story must be re-estimated
  5. The Story has to be tasked out on the Team Board
  6. The Story must be coded
  7. The Story must be code reviewed
  8. The Story must be retested from scratch across all test cases on all devices and browsers
  9. The Story must be signed off
  10. Throughout the Iteration the Team must update JIRA/Rally, talk about the story at Standup and communicate with each other in a timely and effective manner to ensure it passes through the Team’s Iteration workflow.

In short, any story that does not get DONE, even stories that are “99% DONE” will still require a fair amount of work from several people in the Team in the next iteration. Teams should be aware of this and they should focus on getting the maximum number of Story Points DONE.

Why you might showcase NOT DONE Stories

One of the main points of Showcase is to inform the stakeholders on the progress of the work so that they can make good decisions about future work. Sometimes when a Story isn’t done there might be some value in showing this to the stakeholder, but if you do, make sure you are clear with them that they Story in question did not get DONE according to the teams Definition of DONE and that it will be replanned into a future Sprint if it is still a priority. Another reason to Showcase NOT DONE Stories would be to share any blockers the team have with stakeholders who may be able to help clear those blockers.

Turning showcases into SHOWCASES

cast

Once you have been doing Scrum for a while and the Team are comfortable with the Showcase process it’s probably time to dial up the Showcase to maximise the benefits that the Team and business get from it.

Why do we do Showcases?

It lets the business know how the Product/Team/Project/etc are progressing.

If necessary the business can use what they learn at Showcase to change the future direction.

It encourages the team to focus on getting the Stories they Committed to DONE as they know the Showcase will be a public event.

It reinforces the Scrum Values of Openness, Commitment, Courage and sometimes Sense of Humour.

Showcase allows for a celebration and recognition of the hard work of the Team.

Dialling up Showcases

So if we’re going to do Showcases for these reasons then we should do them well as we possibly can.

Get the basics right

For any Showcase to be successful you have to get the basics right. The Team should be ready to go before the booked time. If there are any AV equipment to set up they should book the venue early enough to allow for setup activities. Likewise, if they are working from a laptop, make sure that any urls are preloaded and any logins required are already completed (unless that is what you are showing). Basically they should be ready to start on time and the presentation should be as slick as possible.

The Team should know what will be covered in the Showcase before starting. This should be Showcasing every Story that got DONE in the current iteration.

Stories that are not done, or are almost done, or 99% done, should not be covered at Showcase. If the Team wanted to show these Stories at Showcase they should have gotten them DONE before the end of the Iteration. Showcase isn’t for pretty thing that we’ve been working on. It’s for showing what the Team got DONE. The only exception for this is when there is value in the business knowing about important aspects of incomplete work. If the Team decide to show work that isn’t DONE then they should be clear with the audience that the work is not DONE and why they are showing it.

Get a BIGGER venue

In one contract I moved all of my Scrum Showcases into the kitchen as it’s the largest space in our office and it has a 60 inch television. Move your Showcase into the biggest venue you have. If you don’t have a large TV then try to get a projector. In another contract I moved the Showcase to an onsite auditorium that could seat 200 people. We had eight Scrum teams from a SAFe Agile Release Train showcasing in order and out maximum audience we ever got was probably over a hundred people.

Invite EVERYONE

Make your showcases as public as possible. Invite every stakeholder related to the Stories that they Team are working on. Let the Team know who is invited. Speak to senior stakeholders and make sure they turn up occasionally. Not knowing if the CIO (or other important people) is going to randomly turn up will motivate the team to make sure they do a slick Showcase every time.

Top Tip: Don’t do this until the team have done a few Iterations together and know how to run a good Shocase. No need to humiliate a new team that is just learning the ropes.