Structure of an Excellent Sprint Review
Having an effective sprint review meeting can help your team complete sprints and achieve their sprint goals and objectives. So here is the structure for an excellent sprint review meeting.
Product owner
The product owner needs to come up with ideas on what to expect during the meeting. He needs to identify sprint goals and give a clear context that will ensure the stakeholders have a broader understanding of their progress.
Development team
The development teams’ task is to showcase the potentially shippable product increment and its underlying architecture to the stakeholders.
Stakeholders
Stakeholders should issue honest time feedback on the product and highlight if the scrum team followed the sprint goals. During this period, the participants ask questions to which the development team needs to give answers them.
Product backlog
The product backlog includes all the products that the team didn’t complete. The scrum team and the stakeholders discuss the impact of the feedback they got on any new business issue that the stakeholder gave and how it impacts the product backlog.
At this point, they review the progress of the scrum team in the context of the next release using tools such as release burn down. The sprint team and the stakeholders additionally discuss any new detail concerning shifting customer needs, marketplace, and competitors. They also discuss the company impediments and budgets for sprint reviews that don’t have customers.
Coordination
All the participants need to discuss the steps they should take to ensure the product becomes successful. The focus is usually on the strategies for the next sprint.
Sprint Review Template
Use the below free template to conduct a sprint review session — with an infinite canvas, and pre-built areas to help you organize your ideas and feedback, you’ll hit the ground running and have a single source to reference for your upcoming sprints, as well as to share with any and all stakeholders following your meeting.
Get started with the Mural Sprint Review template
As with all Mural templates, you can share it via a link with set viewing and editing permissions, or export part or all of your mural in a variety of formats, so that it can be easily shared or saved anywhere your team tracks documents.
What Is the Purpose of Sprint Review Meetings?
At these meetings, the Scrum team presents the finished product to stakeholders so that they can make suggestions on what changes need immediate attention. Stakeholders are anyone not on the Scrum team that has a vested interest in the project, like investors, customers, sponsors, and so on. The meeting also allows the Scrum team to make better-informed decisions on how to move forward with any changes in the next sprint. Put another way, the main objective of these meetings isn’t to give stakeholders a status update. It is held to showcase the working product, referred to as the product increment, and gather actionable feedback on it.
The product increment is the sum of all work completed in one particular sprint. While the goal of each sprint is different, all goals are aligned to serve as an essential step toward achieving the final product or fulfilling the product backlog. When the Scrum team and stakeholders understand each other and work closely together, the overall work becomes more efficient and effective. The methodology enables rapid improvement because it’s easier to identify shortcomings and inefficiencies quickly. This also means that each product increment gets closer to the ultimate goal.
What is a sprint review?
A sprint review is an informal feedback session where agile development teams demonstrate the work they completed at the end of the sprint to stakeholders and product owners. Structured as a collaborative working session, sprint reviews help teams showcase the work done over the curse of the sprint, get feedback on what they created, and confirm that they met their stakeholders’ expectations.
The main attendees of a sprint review should be limited to the scrum or development team, key stakeholders, and the product owner. These attendees may vary depending on the content of the sprint or iteration.
Generally, a sprint review should be an hour long for every week of the sprint, but not exceed four hours total. For a two-week sprint, you should plan on a sprint review taking about two hours.
Sprint review vs. retrospective
A sprint retrospective (or retro) is a Scrum meeting that brings product owners, developers, and scrum masters together to go over what went well, what didn’t go well, and what adjustments should be made following a sprint. It’s meant to be a pulse check on how the team handled the last sprint, and an efficient way to identify what to test in subsequent sprints.
Rather than limiting the discussion to the three main questions of a retrospective (the good, the bad, and the adjustments), a sprint review is meant to include an in-depth discussion of what was completed during the sprint, a demonstration of any new functionality, and a question-and-answer session for all stakeholders.
What is a sprint review?
A sprint review is an informal meeting held at the end of a sprint, during which the team shows what was accomplished, while the stakeholders provide feedback. It’s a collaborative working session rather than a one-sided presentation.
Here’s an example of what a documented sprint review can look like in Nuclino, a unified workspace for all your team’s knowledge, docs, and projects.
You can use Nuclino to plan and review your sprints, build your internal knowledge base, onboard new employees, take meeting minutes, communicate asynchronously, and more. It works like a collective brain, allowing you to bring all your team’s work together in one place and collaborate without the chaos of files and folders, context switching, or silos.
Sprint review participants
The attendees of a sprint review usually include the product owner and product manager, the Scrum Master, the development team, the management, various business stakeholders, and anyone else involved in the product management process.
Sprint review timebox
Like all meetings, a sprint review needs to be strictly timeboxed. It typically lasts between thirty minutes and three hours, depending on how long your sprints are. For example, if you are using one-week sprints, the meeting should last no longer than one hour.
A sprint review can also be conducted asynchronously, without a fixed timebox. In this case, sprint results can be presented using a video recording tool like Loom, and stakeholders can provide their feedback in writing.
Sprint review purpose
A sprint review is more than just a demo session held to provide a routine status update. The main purpose of a sprint review is to inspect the outcome of the sprint, collect feedback from all the stakeholders, and adapt the backlog going forward.
When done right, a sprint review can help you create transparency, foster collaboration, and generate valuable insights.
How are sprint reviews helpful?
Sprint reviews give teams the chance to review the progress that they’ve made on their sprint.
Teamwork and collaboration
Sprint reviews help ensure that each team member is involved in the process and is on the same page with their goals and tasks that have been completed this far. They are the ideal time to also update or improve on the timelines for the project if they can’t be met before the final deadline.
Stakeholder engagement
The sprint review meeting allows the Scrum team to collaborate with the stakeholders and get them involved in the product development process.
Maximize quality
It’s a great way to receive feedback directly from the stakeholders involved in the project. By using the feedback they receive, the scrum team is able to leverage their next sprint and improve on insights for the next stage in the sprint.
Who Attends the Sprint Review Meeting?
The stakeholders, product owner, scrum master, developers, management, customers, and the scrum team are the people who attend a sprint review meeting. They discuss the activities they engaged in the last sprint and the changes they need to make to the product. The teams coordinate and settle on what they need to do to achieve an optimized value.
The scrum master is the one who leads the event and ensures all the participants understand the agenda of the meeting. He ensures the forum is time-boxed even though a sprint review meeting doesn’t have a fixed time frame.
The meeting majorly lasts for four hours for a one-month Sprint. However, the time length can be shorter in the case of shorter sprints.
What is a sprint review?
During a sprint review meeting, the Scrum Team and the stakeholders get together to discuss what was accomplished during the sprint. The goal of the sprint review meeting is to ensure that the goals during the sprint where met. This meeting is usually informal and is attended by the Scrum Master, the development team, and the product owner and manager. During the sprint review meeting, the Scrum team presents the product development and the stakeholders provide feedback on their progress.
The duration of a sprint can vary depending on the length of the sprint. A sprint can last one week to four weeks. Typically the total number of weeks a sprint lasts is also the number of hours a sprint review will last. For example, a sprint that lasts one week can have a sprint review that lasts 1 hour. Or, a sprint that takes four weeks will have a sprint review that lasts four hours.
There are a variety of questions that can be asked to ensure that the team members are all on the same page. These questions bring about a culture of delivery for everyone involved in the process. Here are a couple of examples:
- Does everyone understand the team’s values and culture?
- Are there clear definitions and requirements around the code of review?
Just like the duration, the structure of a sprint review meeting can vary. The meeting may be broken down into smaller segments that help manage the flow of the meeting. They typically start with welcoming the stakeholders and end with the product owner requesting feedback from the stakeholders. The segments in-between can be scheduled according to the team’s needs. The agenda can include, presenting the review agenda, presenting done products, and presenting the product backlog.
10 typical sprint review mistakes
- Detailed status of every sprint backlog item.
- Discussion about hours. Remember, in Agile you deliver value, you do not spend time.
- Discussion about capacities.
- The demonstration is not prepared, you click and explain every aspect of the presented functionality.
- The presentation, if prepared, is full of bullets and details. Just in case some people do not attend the review.
- Feedback is not gathered. Use Feedback/Happiness door technique at least.
- The timing is not managed.
- Only the Product Owner speaks in the sprint review.
- The sprint review is done for the Product Owner.
- No sprint review.
Самостоятельная практика Agile
Если вам не повезло, и в вашем учебном заведении даже нет намёков на новые технологии, вы можете воспользоваться советом из книги «К чёрту всё! Берись и делай!» Ричарда Брэнсона и запустить их самостоятельно.
Основатель Virgin Group Ричард Брэнсон по праву считается королём Agile-управления в бизнесе. Он внедрил большое количество инновационных стратегий, которые позволили повысить мотивацию и удовлетворённость сотрудников. Такой подход помог Брэнсону стать миллиардером и завоевать симпатии подчинённых.
Вот несколько вариантов, как это сделать:
- предложите преподавателю организовать групповую работу в учебных командах в качестве эксперимента;
- используйте элементы Agile-методологии при подготовке к самостоятельной работе;
- организуйте среди одногруппников, интересующихся темой, клуб для проектной работы;
- изучайте опыт мировых компаний, которые активно применяют Agile и Scrum для повышения эффективности персонала.
Отличия традиционного подхода от «гибких» методов
Итак, в чём же отличия традиционных подходов в образовании от современных гибких методов? Для удобства и наглядности мы собрали их в одну таблицу:
| Традиционный подход в обучении | Agile-подходы в образовании | |
| Период обучения | от трёх месяцев до полугода | короткие спринты от одной до двух недель |
| Формат обучения | соответствие строгому учебному плану | обучение построено как игра |
| Форма организации | общие лекции и семинары | практические группы от 6 до 8 человек |
| Форма восприятия информации | пассивное восприятие | активная самостоятельная работа в группах |
| Оценка результатов | внешняя оценка | внутренняя оценка |
| Роль преподавателя | полностью контролирует весь учебный процесс | направляет и корректирует |
Что такое Agile и Scrum
Прежде, чем говорить о применении Agile-методологии и scrum-технологий в образовании, давайте разберёмся, что они обозначают.
Agile и Scrum — это понятия, которые пришли из IT-сферы. Разработка инновационных продуктов совершенно не похожа на стандартный процесс производства, где есть чёткий план, сроки и бюджет. Здесь часто приходится решать задачи при большом уровне неопределённости и находить новые пути. Именно для этого и разработали эджайл-методологию.
Agile — метод и образ мышления
Многие определяют Agile как общее обозначение целого ряда «гибких» подходов, применяемых для разработки продуктов программного обеспечения. Это верно, но не совсем. Agile — это скорее определённый образ мышления и культурные особенности, которыми характеризуются эти подходы. А потому эджайл можно применять не только в разработке, но и в других сферах.
Agile-мышление опирается на четыре важные ценности:
- На первом месте люди и взаимодействия между ними, а не процессы.
- Акцент на продукте, а не на регламентах и документах.
- Тесное взаимодействие с заказчиком, а не бесконечные согласования по факту.
- Постоянные эксперименты и изменения в процессе, а не строгое следование плану.
Подробнее о 4 ценностях и 12 принципах методологии для IT-разработки можно почитать непосредственно в Agile-манифесте.
Вдохновлялись создатели Agile-методологии научным методом, который разработал ещё Галилео Галилей. Что роднит IT-разработчиков и итальянского учёного? В основе двух подходов — постоянное повторение эксперимента и уточнение результатов.
Фреймворк Scrum
Scrum — это один из самых известных и популярных фреймворков, или подходов Agile-методологии. Иначе его ещё называют «подходом структуры». Разработкой метода занимался Джефф Сазерленд, бывший военный лётчик, и его подход изначально не отличался особой гибкостью. Скорее наоборот.
Скрам предполагает чёткое распределение ролей и последовательность процессов. Над каждым проектом работает небольшая команда специалистов, действия которых координирует владелец продукта и scrum-мастер. Первый следит, чтобы результат соответствовал первоначальным целям, а задача последнего — корректировать и направлять действия команды в соответствии с методологией. Вся работа состоит из коротких спринтов (одна-две недели), в начале которых определяются цели, в конце — сравниваются результаты и происходит корректировка. Каждый выполняет свой отрезок задачи и непосредственно влияет на процесс. Такой подход позволяет быстро создать продукт, поддерживать высокую мотивацию команды и не тратить время и деньги на неэффективные действия.
Не менее популярен фреймворк Kanban. Его называют «подходом баланса». В канбане в отличие от скрама нет ролей и строгих подходов к процессам. Главная цель — быстрое продвижение задачи по разным этапам: «Планирование», «В разработке», «На тестировании», «Завершено». Именно в канбане активно применяют scrum-доски для визуализации процесса.
Scrum-доска позволяет визуализировать рабочий процесс
What is a Sprint Review Meeting?
Sprint review meeting refers to a meeting which a company holds at the end of a sprint and presents increments to increase collaboration among the members and acquire customer feedback on their refined products. Its main aim is to survey the increment and adapt the product backlog where necessary.
Sprints are the heartbeat of Scrum. They are time-boxed events where the team and stakeholders work together to assess their progress, uncover and remove impediments, and plan work for the next sprint. A sprint review meeting occurs at the end of the sprint for the stakeholders to see what they produced within the sprint cycle. It is an important day for the team because they show off what they’ve built and learn how their product would be used in a broader context.
Sprint review meeting agenda
Whether you prefer to conduct your sprint reviews in-person or asynchronously, make sure to prepare the meeting agenda in advance and take meeting minutes. Having a written record of your sprint reviews helps you preserve the context of every decision and makes it easier for remote, absent, or newly joined team members to stay in the loop.
There is no strict format for the sprint review meeting, but it usually begins with revisiting the goals of the sprint. The product owner explains the backlog items that have and haven’t been completed during the sprint. After that, the development team demonstrates the work that was done, answers questions, and receives feedback. Finally, the whole group collaborates on the next steps, providing valuable input for the upcoming sprint planning meeting.
The sprint review meeting agenda typically includes the following topics:
-
Sprint goal review. What did we set out to accomplish? What was accomplished? What is still unfinished?
-
Demonstration. What was built? How does it work?
-
Feedback. What feedback or questions does the rest of the team have?
-
Release plan. What is the current release plan? What are the expected delivery dates?
-
Discussion. Do we need to make changes to the plan?
-
Next steps. What tasks should come next?
Sprint Review Agenda
The sprint review meeting should not be very long, 45 minutes + 15 minutes for discussion. It should have its flow and energy. Make it energized, valuable and stakeholders will return for the next sprint review.
Every part of the meeting is ideally provided by a different role. All roles (agile development team, Scrum Master, and Product Owner) are included in the presentation of sprint results. This way, your Sprint review meeting will be entertaining and not just another boring demo session.
Following is an example of the invitation to the Sprint Review meeting sent by Scrum Master to stakeholders of the agile team. Adapt time slots to your needs, but not make them too long. People lose concentration after 45 minutes. Therefore, take appropriate breaks if you need to do a more extended sprint review.
Sprint review agenda
What happens at the Sprint Review
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment or the Marketplace. Based on this information, all attendees at the Sprint Review collaborate on what to do next. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation or team building event.
Product Goal
In order to keep the team heading in the right direction, the Product goal should be reiterated at every opportunity, including the Sprint Review. This is an opportunity to remind both the Scrum Team and the Stakeholders what we are aiming to achieve as a way to focus the conversation on what matters.
Sprint Goal
At the Sprint Planning meeting for each Sprint, the Scrum Team creates a Sprint Goal which describes WHY the Sprint is being delivered. Ideally, each Sprint should be a step towards the Product Goal and should describe the highest ordered Product Backlog items which were pulled into the Sprint.
Review Market Changes
Any Market changes which may impact the Product should be presented at the Sprint Review meeting. This information will help the Scrum Team and its stakeholders to better provide feedback and better understand the Product Owner’s reasoning behind the order of Product Backlog Items in the Product Backlog.
Explain what was done and not done
For Transparency, the Scrum Team may choose to describe which Product Backlog items were originally planned for the Sprint, and which of those Product Backlog items were done — or not — by the end of the Sprint. This level of Transparency can be uncomfortable for teams, but it provides stakeholders with key insights into the issues which the team is facing and may be an opportunity for the Scrum Team to request assistance with removing impediments.
Demonstrate working software (or the Increment)
For software development Products, the team may choose to provide a live demonstration or a presentation of the done increment in order to give stakeholders and opportunity to react to what was done and to provide feedback. You do not need to demonstrate every single Product Backlog Item which was delivered as part of the Sprint, but be sure and cover the most valuable Product Backlog Items which were delivered. Frequently, the Developers facilitate this part of the Sprint Review meeting because they are closest to the work and best able to answer any questions that may arise.
Collect Feedback
This is the part of the Sprint Review that is most frequently skipped for newer teams. Many teams do not do enough to encourage sprint review attendees to provide feedback.
Review Forecast
The Sprint review might conclude with a discussion of the Product Forecast. The Forecast is a prediction of what features or functionality might be delivered next, and when.
What is the Purpose of Sprint Review?
A team needs to deliver a potentially transferrable product at the closure of every sprint. A potentially transferable product refers to a team that has built a coded, tested, and a usable chunk of software. The primary purpose of a sprint review meeting is for the members to showcase what they achieved during a sprint.
The sprint meeting is significant to a company as it motivates and inspires the team to work harder. It also helps them to learn and share their best practices, and brings attention to impediments and delays. They also get a chance to review assumptions, and course corrections that the team made.
Conclusion
A sprint review meeting is an integral part of the Scrum process that every organization needs to implement. It allows the company to show its progress and define the next steps for further work. The product owner and the development team use the time to communicate and discuss what they achieved in the last sprint, what is remaining, and how to resolve the issues. It is vital to set up a sprint review meeting towards the end of each sprint period. A sprint review meeting allows you to analyze how well your team performed during the sprint and identify bottlenecks before they turn into showstoppers.
Используйте “Закон Двух Ног” (англ. Law of Two Feet).
Если в ходе обсуждения какой-либо человек окажется в ситуации, когда он не узнает что-то новое и не подключается к обсуждению, он может пойти в более полезное для него место.
Как в PandaDoc используют формат Open Space на Sprint Review
Давайте рассмотрим как мы адаптировали формат Open Space в PandaDoc.
Мы повсеместно используем Miro внутри нашей организации, и конечно же для повестки дня и создания матрицы ивента.
У нас есть матрица 3×5, которую при необходимости можно расширить до 4×5 или 5×5. Этот общий план заполняется во время спринта, когда команды добавляют темы презентаций в доступные временные интервалы.
В четверг, за день до нашего двухнедельного обзора спринта, мы делимся этим общим планом в компании и приглашаем людей присоединиться. Это обеспечивает прозрачность для процесса ревью, заранее уведомляя участников о темах, которые они хотели бы обсудить.
Мы проводим наши Sprint Review в Zoom. Каждая встреча длится 85 минут (иногда короче, но никогда не дольше) и включает в себя такие три части как: питчинг, демо, завершение.
Питчинг: 20-30 минут
Во время этой части ивента участники предлагают и приглашают людей на демо-сессию, а также демонстрируют общую динамику своей работы.
Эта часть встречи очень важна, потому что за этот короткий период времени она:
- Показывает общий road map с подробным описанием наших результатов работы и планов.
- Делится текущим состоянием product delivery.
- Дает общее представление о направлении работы команды.
После этой части фасилитатор (обычно это Скрам Мастер) делится окончательным планом и объясняет правила формата Open Space. (Мы кратко объясняем правила каждый раз, когда в команде есть новые участники.)
Мы также объясняем как работает функция Zoom Rooms и напоминаем участникам установить последнюю версию Zoom, которая позволяет людям самостоятельно переключаться между комнатами. Мы также объясняем, как выбирать комнаты и перемещаться между ними во время встречи.
После этого фасилитатор всего ивента открывает Zoom-комнаты и наступает вторая часть ивента — демо.
Демо: 50-60 минут
В каждой комнате есть свой модератор (как правило, это Скрам Мастер), который ведёт обсуждение, следит за временем и ставит демо на видеозапись. Мы записываем все Zoom-сессии на тот случай, если кто-то не может присоединиться, но хочет посмотреть видео позже.
Наша логика заключается в том, чтобы создать пять комнат: три для демо (согласно agenda) и ещё две комнаты под названием «кулер для воды» и «курилка / комната для курения», где люди могут продолжить обсуждение любых тем и функций.
Завершение встречи: 5 минут
После демо-части мы оставляем пять минут для того, чтобы все собрались вместе в одной общей Zoom- комнате, где каждый может поделиться обратной связью, комментариями и благодарностью.
Фидбек и следующие шаги / действия
На момент написания этой статьи, мы успешно провели семь Sprint Review в формате Open Space.
Вот посмотрите, какую реакцию мы получили от нашей команды:
Не смотря на то, что люди в целом довольны нашим новым форматом Sprint review, мы всё же планируем внести несколько улучшений в следующий раз:
- Обратной связи всё ещё не так много, поэтому мы надеемся повысить её качество и регулярность.
- Общий объем (скоуп) демонстраций обычно сосредоточен вокруг достижений в спринте, поэтому мы также хотели бы обсудить каждую фиче “стори” — не только её текущее состояние, но и её прошлое и будущее.
- В заключение, мы надеемся продемонстрировать элементы, не только связанные с поставкой ценности, но и результаты исследований и обзоры проработанного дизайна, которые могут привлечь ещё больше участников к каждому демо.
Надеюсь, эта статья была для вас полезной! Делитесь ей, комментируйте и оставляйте отзывы!
Перевод статьи осуществлён Дмитрием Незабытовским
Definition of Sprint Review
The sprint review, or commonly the sprint demo is a meeting that takes place at the end of the sprint, where the team showcases their “potentially shippable product”. Generally I don’t like the name “Sprint Demo”, this should not be the first and only time the product owner sees the product, or the stakeholders for that matter.
“I love those who can smile in trouble, who can gather strength from distress, and grow brave by reflection. ‘Tis the business of little minds to shrink, but they whose heart is firm, and whose conscience approves their conduct, will pursue their principles unto death.”– Leonardo da Vinci
The aim
The aim of the sprint is to get to a point where you have a product that has been coded, tested and is usable — and can be deployed into production. The purpose of this meeting is to inspect the product, to verify that everything agreed has been accomplished.
The product owner will usually invite all relevant stakeholders to review the product, and give feedback to the team.
The common phrase heard regarding this meeting is: Inspect & Adapt. It allows the product manager to inspect the product and gauge if it’s what he wanted. To see if he is happy to release to production and how to move forward in the next iterations. The meeting should not be just a demo of the software (hence why I dislike the term Sprint Demo), the product owner takes this milestone as a chance to review the increment delivered, and how to adapt for the next sprint.
Is it just a demo?
If you review the product and simply demo it, you might think that the meeting was a success, when in actual fact you are missing the point of the meeting completely. On the outside, this seems one of the easiest meetings to do in Agile or Scrum — but in actual fact it’s one of the most delicate.
Tips for an Effective Sprint Review
Sprint review meetings are all about team communication. The team demonstrates to the Product owner that they can deliver maximum value in minimum time by collaborating and communicating their progress and any obstacles. However, after a week of hard work, everyone is tired and wants a good sprint meeting. But how do you organize it? How do you make it efficient and effective? Here are some tips to help you run great sprint reviews.
Set an Agenda
Review the sprint outcome, showcase the work, collect feedback and update the project and strategies for future work.
Time-boxing
Ensure the meetings are short and precise while adhering to the agenda. Short sessions motivate the team to attend and give their views, unlike long tiresome meetings.
Maintain user language
All the participants in the meeting are significant. The scrum master should then ensure the language they use is common to all and easy to understand. They should avoid using technical terms or slang, which can lead to misunderstanding.
Opt for an alternate format
Incorporating a new format may result in new energy in the sprint, which is very significant in ensuring the success of a project.
Avoid judgment
The members should not give critical judgment, instead, they should give constructive feedback. All the participants should feel free to share their input without being criticized.
The participants should give their user stories.
When the team members give their user stories, they feel appreciated and get the chance to interact with the end-users, which allows them to take ownership of the task at hand.