Sprint Demos vs Retrospectives – What’s the Difference Between the Two?

Sprint Demos

The purpose of a sprint demo is to showcase what has become clear in the sprint. The team’s role is to demonstrate to the Product Owner this fact. Product Owner role is to check whether the delivery meets the sprint goal, to approve or refuse the delivery and to provide feedback to the team.

Often the sprint is part of something larger, to be delivered a number of sprints ahead. Therefore, it may be wise to briefly mention some direction and clarify the wider context, for example, by using a mind map.

Participants at the sprint demo include the whole team together with the Scrum Master, who ensures that the agenda of the sprint demo implemented. Essentially, the team is working together to prepare a demonstration for the product owner.

On his or her part, the Product Owner prepares any potential stakeholders who join the sprint demo so that they have the right expectations during the meeting.

Examples of other stakeholders include: customers, sales organization and neighbouring teams. It is important to demonstrate only the actual increment. Focus on what’s “fit for purpose”.

It is important that the team does not wait for the sprint demo to show their present, obtain feedback or ask questions to the product owner. Dialogue must take place throughout the development process, not just during the sprint demo.

A sprint demo should never contain any surprises for the product owner!

Sprint Demo – Proposed agenda

• Sprint goals and outcomes.
• Demo of delivered functionality (focus on “fit for purpose”).
• Discussion of challenges, such as technical liability and factors that prevented the team to achieve its objectives, including emergency breakdowns and absence.
• Delivered impact of functionality in relation to current priorities and/or vision.
• Discussion of the next sprint.

Product Owner role during the sprint demo

• Check that what is delivered in the sprint match sprint goal.
• Check if the acceptance criteria are met.
• Accept or reject the delivery.
• Provide feedback to the team.
• Answering questions from the team and other stakeholders.
• Identify new requirements and needs, it is not uncommon for new requirements emerge during the demo.
• Plan ahead for the next sprint.
• Suggest ways to make the functionality better and thus increase benefits further.

Tip: Give both praise and criticism when needed. Confirming the team’s effort, but they also need to know what you are not satisfied with.

Retrospectives

A sprint demo focuses on what has been delivered. A retrospective focuses on how the work was done.

A retrospective meeting concludes the sprint. The aim is to look back at the sprint that has been to learn, develop and improve. If you do not retrospective, the risk is that it repeats the same mistakes again and again, and that you do not actively choose to improve what needs improving.

If you have a two-week sprints, are also retrospective after these two pins. Each time, always. Same time, same place. This is the team meeting. Because it is an internal process, the scrum master, which ensures that the meeting happens. Often it is also the scrum master leading the meeting and holding the exercises being done.

The Product Owner regularly participate. If you as a product owner cannot attend, ask for feedback, e.g., via email.

During the meeting, ‘the team themselves with the help of dialogue and exercises that will help the team to compile their experiences. Everyone participates in joint responsibility.

It is important to plan the retrospective in a good way. If you are using the correct exercises, will be the meeting efficiently and to arrive at good conclusions. If you feel that the meeting will be routine, might have chosen the wrong techniques or planned in the wrong way. Properly used, technology provides efficiency and power.

A draft agenda for the retrospective would include:

• Analysis of the burndown chart.
• The team assesses themselves. Examples of areas to evaluate: velocity, estimates, collaboration, quality, time, processes, tools.
• What went well? Why?
• What went badly? Why? What needs improvement?
• Summarize what you come up and possible measures, turnover pleased to something that can be implemented in the next sprint.

Tip: Do not let go! It is easy to see that something needs to be changed but forget how it should be implemented. Document the decisions, reappeared, follow up at the next meeting. Insert the end date.

Examples of exercises used in retrospective

Draw a starfish with five arms on the board. Write the following headings on the five arms: Start, stop, keep, more of, less of. Let the team brainstorm on activities for the various headings. Each participant writes their ideas in silence on post-it notes. The exercise takes 5-10 minutes.

Afterwards go through the ideas, rank, decide which ones should be addressed and assign any related tasks to a person with a deadline.

Another favourite exercise of ours is to ask oneself: if this sprint were an animal, what animal would it be? If this sprint were a colour, what colour would it be?