Home > Agile Development > Public sprint demo

Public sprint demo

September 28th, 2009

Imagine that your team is developing product for some market. There is no specific customer yet, so product owner is an internal product manager. And at some point you realize that there is lots of functionality, but from user’s point of view it just doesn’t work at all – bug here, bug there, small, but very important piece of functionality is not implemented because team is comfortable adding data via database. Product owner expresses his concerns from time to time, but it doesn’t help. Developing first version of product is quite difficult task and team loses its enthusiasm as they don’t see real customer. End quality is decreasing. What to do?

In Scrum there is a concept of sprint demo – meeting, when new version is shown to customer (product owner). Usually it is held privately – the team, product owner and possibly some stakeholders. Making sprint demo public is neither prohibited nor promoted by “best practices”.

Public sprint demo can provide the company and the team with several advantages:

  • Awareness of public presentation (especially to peers) creates stronger commitment
  • Awareness of public presentation makes the team think about usage from user point of view – they have to demonstrate it to the public
  • It leads to more stable product – nobody wants to demonstrate how unstable the product is in front of peers
  • Public presentation makes other people aware of what is going on therefore increases transparency and unites company
  • Public sprint demo allows the team to show off their achievements therefore increasing satisfaction
  • It increases presentation skills of the team, makes them used to public attention
  • Attendees can give valuable feedback on the product
  • Successful public sprint demo gives the team strong feeling of great achievement

Sometimes it is not possible (or doesn’t make sense) to conduct a public sprint demo. For instance:

  • When contract prohibits demonstration of the product even to other employees of the company
  • When product has no visible features to demonstrate, e.g. technical framework. Although if there is a sample built on this framework the team can use the sample to demo the framework

Difficulties

Of course, if public sprint demo was easy to conduct then it would be held much more often. In fact, it is not. There are many difficulties, main of them are:

  • The team is afraid of public demo
    • They are not used to work with wide audience
    • Team members are afraid of criticism – support from project manager/Scrum master/one of stakeholders is helpful
    • The product has a lot of bugs – next time the product will be more stable
  • Company is so disconnected that no one is interested in others’ work – I believe that’s a serious problem and public sprint demo is a good indicator of it
  • After unsuccessful sprint – in this case it is especially useful to make public sprint demo. It will make the team analyze and think over mistakes made. In the same time make them realize that it happens and it doesn’t make sense to think that the life is over – instead they have to think how to avoid the same problems in the future, therefore making them more resilient and able to tackle difficult situations.

Tips

When the team conducts the first public demo surprisingly many people may come. So, it makes sense to conduct public sprint demo in some kind of conference room with enough of space and projector to demonstrate the product on big screen. The team should create demo scenario and test data in advance (it makes them think over how it looks from user perspective).

Results

Story in the beginning of the article is a real-life one. Did public sprint demo help? Yes.

Initially there was strong resistance to idea of public sprint demo. Although after some pressure from project manager the team agreed to conduct it. Main concern of the team was that nobody would come. Surprise – so many people came to the first demo that the demo moved to a bigger room.

The product became much more usable and stable. The team’s morale increased. Public sprint demo brought some fun and in the same time improved results.

It’s worth trying it – you may get pleasantly surprised.

Categories: Agile Development Tags:
  1. No comments yet.
  1. No trackbacks yet.