Agile Successful demo in a distributed team

    Project Demonstration, Sprint Demo, Sprint Review, Iteration Increment Show - we are all familiar with the different names of the same process event of the Scrum framework. The purpose of these meetings is to show the stakeholders and project budget owners everything that the team did at the end of the iteration. We all know how important this meeting is and how, in theory, it is simple - just gather everyone and show what you have done.
    Below is the experience of a real project. We will consider the main problems, and then focus on the aspects of effective preparation and successful demonstration of sprint results.

    Project Overview


    The team is developing a key product that is used throughout the entire company. He has over 10 key stakeholders in Moscow and another 10 around the world. More than half of them are top management (very busy people). Product owner, team leaders and analysts are located in Moscow. Scrum Master and the development team (about 15 people) are located in Dnepropetrovsk.


    How it was


    So, the easiest way is to just ask everyone to come and see. And it was this way the team went.
    However, the following happened:

    The meeting began with a delay of 15 -20 minutes
    • The team was waiting for all the invitees
    • The team began preparations at the beginning of the meeting: WebEx, audio conference, connection to the system, etc.
    • Microphones did not work or did not work well.

    Chaos at the demo
    • It was not clear to everyone what time the demo session started and ended
    • Lack of a clear demonstration plan
    • Lack of a demo session leader
    • A lengthy discussion began outside the demo goal
    • No one fully understood the meaning of this meeting

    Only participants from Moscow took an active participation
    • People from other locations did not hear the discussions and were unable to communicate with other participants in the meeting

    Lack of clarity and transparency
    • Participants did not understand what was shown
    • Participants did not understand the project status as a whole
    • Participants received a large number of complex and unclear slides

    Incorrect user stories
    • Part it was impossible to demonstrate
    • Use of test data: “12345”, “qwerty”, “test surname_1”. Participants did not understand how this would work in real life.
    • The actual volume of user stories was unclear. It was difficult to understand whether this story was completed or not.
    • The reasons for choosing the implementation were not clear

    Technical stories were shown to completely non-technical people . A large number of technical details were not acceptable for such an audience.

    Forgotten Action Items . There were a lot of points that were either lost after the meeting or misinterpreted.

    Solutions and methods that helped


    So, everyone understands that this meeting was not effective. What methods have helped improve the situation:

    Creating recurring appointments . We created repeating meetings in Outlook - all participants always knew where and what time the next demo will be. This allowed all participants to plan their schedule in advance.

    Schedule preparation. Now, everyone who was responsible for conducting the Demo had time to prepare (starting an audio / video conference, checking the connection, availability of the conference room, etc.). All this was done so that when the interested parties came to the meeting, everything was ready and we could start.

    Determining the conditions for starting. We decided that the demo begins exactly when the key participants (2-3 people) are present. Now all interested parties know that we start exactly when the key participants come and there will be no more delays.

    Strict meeting agendas . Demo follows according to agenda. Agenda is scheduled and reminded before each meeting. Now everyone knows when this or that item will be discussed and chaotic discussions do not arise.

    Working agreements . This is a tool to maintain the effectiveness of the meeting and maintain focus on meeting the goal of the meeting. Working agreements are written on a marker board on each Demo. Demo leaders can use them as a discussion management tool.


    “Parking Lot”. When the discussion goes beyond the bounds of the agenda or takes too much time, the leader of the demo puts it in the “parking lot” as an Action Item. Any Action Items that occurred during the meeting are also placed there.

    Handouts . We printed colorful handouts so everyone could see presentation slides and be able to take notes for themselves. It is also useful for the projector to display not only a presentation, but also a working application.

    Agile Charts . We changed all slides with release or sprint status. Previously used the "classic approach", we made it more "agile". This has increased understanding of progress.

    It was:



    It became:



    Demo Leader. We introduced the demo leader role. This is only one presenter in the conference room who runs the demo, gives others the right to vote, keeps track of time, agenda and uses working agreements as a tool for managing the demo. Now everyone knows who is the leader and who has the right to manage the meeting.

    Assistant in another location . We made one of the team members in Dnepropetrovsk an assistant to the Demo Leader. The assistant controls everything that is displayed on the screens and can connect team members to discussions. The assistant also manually adds Action Items to the Parking Lot so that everyone sees in real time that everything is written and written correctly.


    Video Bridge. We rejected the boring and inefficient audio conferencing and introduced a video bridge. The presentation and application were shown using projectors. Now, stakeholders and team members not only see the application and hear the presentation, but can effectively communicate when they see each other.

    Delete technical stories . We removed technical stories from the demo because they are not interesting to interested parties and can be misleading. But for everyone who wants to see them (for example, if there are technical guys among the interested parties), a time interval is allocated immediately after the demo for their display.

    Question marks . The question mark is a very fast and effective mechanism for stopping the demo. This works better than trying to interrupt a talking person from another location.


    Receive custom stories at another meeting . We made another meeting, before the demo for accepting stories (using the acceptance criteria defined by the product owner). The detailed acceptance process is not interesting for interested parties - they are not interested in showing each story in detail. So on the demo we show only user stories accepted by the product owner, collect feedback.

    Fast feedback . We ask the interested parties after the demo to give quick feedback on the organization of the demo (what was good and what was not). This helps us to improve the quality of the demo continuously.

    Retrospective demo . We have a short flashback after each demo. This helps improve weaknesses.


    That's all. There is no magic, rocket science, complex solutions - this is just a series of simple but powerful methods that helped the team become more effective in conducting the demo and made their customers happy.

    This is not a complete list of what can be improved in the demo. Why is there a demo in Agile, how to conduct it effectively and much more, we reveal in detail at our trainings .

    How do you do your demos?

    Also popular now: