If I were you, I would attend sprint review. Make your sprint review great.

This article has been published on ScrumDesk product pages.

In the last week, I attended a couple of sprint review sessions. Some of you maybe call them sprint demo. Ok, simply to say, the meeting at the end of the sprint where you are supposed to show your sprint’s achievements. In my case, all sprint review sessions had something in common. People were missing.

About the sprint review

In Scrum, sprint review is a session that closes a sprint (10-15 days iteration) in which completed functionality is demonstrated to the client’s representatives. Very often such review is called Sprint Demo because it is suggested to provide that information in form of live demonstration showing completed functionality.

For the business, this is definitely different comparing to previous, waterfall like process. They see the results very often and regular, which helps to adopt the product according to changes on the market constantly.

In ScrumDesk we help with agile transformations as well. We found that such a demo is nice at the beginning of an agile transformation, important information is, however, still missing for the business. Working in the sprints don’t give you a whole picture of the product status. Being the business you definitely need to understand wider context than just a sprint.

Therefore after few sprints, we guide agile teams to do sprint review and not just the demo part.

But still, people are very often missing in the sprint reviews….

If I were stakeholder, I would like to attend sprint review

Let me ask you a question. What do you think about your IT? The answers we often hear from business side are:

• We do not know what they are working on.
• Everything takes much longer than promised.
• They play some games we don’t understand.
• They don’t collaborate with us.
• We can’t collaborate with them.
• We don’t care what they do, we want results.
• They are telling us NO. Always. Every time.
• IT is lazy.

Maybe you are correct but let me ask you another question. When was the last time you gave IT your ears? Good agile teams want to be proud at the end of the sprint. They want to show you their work and real results.

What good agile teams want the most is your feedback.

If you are not at the sprint review session, there is no feedback. If there is no feedback, no emotion, there is no motivation.

If there is no motivation, there is just a job. If there is ‚it is just a job‘ mindset, there is no creativity. If there is no creativity, there is just an average product.

The average product means business declining in a long term. That means additional pressure on you, dear business. Now you have to „fight“ for your rights and work with the unmotivated team that is doing exactly what you want, will not do anything you did not ask.

You have to write 100% requirements that IT is going to analyze for weeks just to have arguments for upcoming war tension. Meanwhile, your business is going to change once again (even earlier than expected), but hey, you are just arguing about analysis.

Who lost? Everybody. Every person in a company. But especially your clients.

Just because you did not have a time, you were in another meeting, you did not pay attention, you did not provide honest feedback.

If I were team member I would attend sprint review

Sprint review is not just a session for you ScrumMaster or Product Owner, and it is not the session of the team for the team itself. Sprint review is the session with real faces representing the business.

Sprint review is a moment of truth, honesty, shame, and proudness.

Once the sprint itself and the sprint review session is done fine, you will leave the room with engaged, satisfied with your work. That can’t be achieved via training or coaching.

The satisfaction will come in sentences of recognition, honest feedback, claps of hands. That way you will know how you change the world and not just spend another 8 hours (at least) of your lifetime.

But they don’t come

Do you often say: „They are not coming to our demo, why we should run it?“. The answer is not THEM. The answer is about YOU.

Great demo invites people for the next sessions. It if is boring or nobody understands what you say, they will never come back. They do not want to lose life time similar to you.

Make it entertaining, funny, unique, human and they will come back. Give them crisp information. Surprise your audience. Satisfy them. Invite them into the conversation. Do not just broadcast.

How to prepare for good sprint review?

Start before the sprint planning session. Yes, you read that correctly. Before the planning, Product Owner should imagine sprint review session and especially the opening.

Which 3 goals you want to aim in the sprint for?

These three goals will be fulfilled by multiple backlog items. The most important can be recognized up front so the ProductOwner can even guide team members which user stories will be necessary to demonstrate at the sprint review session. Much easier for them to prepare for the demo.

Always talk in business language. We found very usable simple principle.

There should be no technical term in sprint review.

Try to communicate why you developed something, what kind of pain you remove, which job and whose job is simplified. Communicate in a language that audience understand, they can directly imagine an impact on their life.

Keep it short and simple. Guy Kawasaki, great speaker, and entrepreneur define great presentation with the 10-20-30 principle. 10 slides, 20 minutes, 30 points font.

Well, in the demo you maybe do not need to have a presentation (btw, it helps a lot from real life), but 10-20-30 is applicable even in the demo:

• Maximum 10 screens + pictures+ videos + slides at all. Less is always more!
• Maximum 20 minutes. Save additional for questions, answers, for the feedback. For reasons why sprint review is held. Less is always more.
• No small letters, no barely readable texts. Smaller is not always more :).

In all cases prepare for the sprint demo part:

1. Prefill data in the form.
2. Prepare screens for edge cases if you need to show them.
3. If something takes more steps, record a video and speed it up.
4. Show time-lapse.
5. Connect to all necessary services, shared folders, etc. Who wants to attend yet another demo where you see login name admin with password *******?
6. If you show performance improvements, compare them with the previous version. We want to hear gains. Don’t provide just %. Talk to us in milliseconds, a load of x thousands of users, etc.
7. Comment charts with bubbles so we can read them later. If necessary.
8. Put only title, not whole explanation of problems. Talk about details, but do not write it because you will need to use 6pt fonts.
9. Know who to invite and mark as mandatory in the invitation. The outcome might not be interesting to everybody. But do not exclude people from the review. If they want to attend, if it is their willingness to invest their life into your session. Welcome them!
10. Do rehearsal. Do not be ashamed. Great speakers are doing them as well. Keep training in front of your team colleagues. Ask for their feedback.

Five tips how to demonstrate functionality

1. Describe the problem, pain or job, or gain.
2. Mention who is a persona doing that job, having the pain.
3. Explain what it is expected as the correct result.
4. Demonstrate the functionality. Simply, straightforward, without technology words.
5. Ask for feedback.

Keep the timing according to the agenda. ScrumMaster is responsible for that. ScrumMaster moderates the sprint review. The Product Owner is a leader of the meeting. She represents the team, the head of the development body. Team members demonstrate functionality.

All team members participate to some extent in the sprint review session.

Product owner+scrum master + team.

 

Proper agenda of the sprint review session

10 mistakes

1. Detailed status of every sprint backlog item.
2. Discussion about hours. Remember, in Agile you deliver value, you do not spend time.
3. Discussion about capacities.
4. The demonstration is not prepared, you click and explain every aspect of the presented functionality.
5. Presentation, if prepared, is full of bullets and details. Just in case some people do not attend the review.
6. Feedback is not gathered. Use Feedback/Happiness door technique at least.
7. The timing is not managed.
8. Only the product owner talks in the sprint review.
9. The sprint review is done for the product owner.
10. No sprint review.

How does ScrumDesk tool help with great sprint review?

Our vision is to provide the tool for Scrum teams which saves a time and energy with boring stuff. We saw how more than hundred of ScrumMasters prepare for the sprint review session. We were keen to understand what kind of information they have to provide to the stakeholders. What we saw were dozens of minutes spent on the preparation itself. We are pretty sure that for those ScrumMasters this is not a way to live a life.

Therefore, we built the sprint review document directly into the tool from which it can be printed, saved to PDF and then sent to stakehodlers. All done in one minute, you do not need to work on the presentation for one hour.

With ScrumDesk you can, however, prepare far sooner before the sprint review for the sprint review.

1. Product owners can manage agile roadmaps to focus on the right things in mid- and long-term.
2. Every sprint can have goals defined by the product owner.
3. The product owner can mark user stories that should be demonstrated with help of color, or tags, or flags.
4. The sprint review document contains everything you need for real agile sprint review session. Its design is based on dozens of agile teams presentations and sessions we attend. Based on the feedback of ScrumMasters it saves an hour of ScrumMaster in the preparation of an overview at the end of the sprint.
5. Screenshots, movies, time lapse can be attached to the user story directly. Have one repository for all assets.
6. Comments can be provided directly to user stories even by guests. We offer free guest licenses for your stakeholders.