It may be helpful for You to first read articles about Agile and Scrum Framework (you can find both in Sailing Byte’s knowledge base).
How to plan sprint meetings?
Nobody likes meetings that do not bring a reasonable amount of value.
This common truth applies to all meetings including those defined in Scrum framework as Scrum Events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). If those events do not bring enough value, Scrum Master has to step in to help everyone define what we need to change in order to not waste time. Scrum Events do not have any “value” by themself and they need to be properly prepared as any other meetings.
Sprint Planning & Sprint Review are standing out as the most challenging Scrum Events due to involvement of multiple interest groups (developers, product owner, project sponsors and other stakeholders). What is crucial is to focus during each of these meetings on common interests & goals important for all those interest groups. Otherwise those meetings can shift towards either witch hunting spectacle - “let’s find who is solely responsible for this disaster!” (Sprint Review) or 3 hour discussion about the smallest detail of a not so important task (Sprint Planning).
Find out how we can define those common interests
Sprint Review
Focus on goals that will eventually bring value out of meetings.
Sprint review’s purpose is to “inspect the outcome of the Sprint and determine future adaptations.” What does it mean is that Sprint Review is a perfect time for:
1) Scrum team (Developers+Product Owner+Scrum Master) to show what they achieved in terms of obtaining Sprint Goal;
2) Everyone present at Sprint Review to give feedback about what they just have seen or have been testing/using. ;
3) Everyone present at Sprint Review to help adjust future development plans to either align more with the current Product goal or adjust Product Goal.
As we clearly see, everyone needs to bring significant input into Sprint Review to create a mutual, common interest. It may be tempting to consider Sprint Review as only a “developers presentation” (aka demo) but in this case why do we even need a meeting ? Developers should just send an email with a presentation/sprint summary to all stakeholders and wait for separate feedback. What do we miss here ? We are not giving ourselves the opportunity to experience a teamwork session thus there is no place for common interest to emerge.
There is no such thing as “perfect script” that will suit every sprint review (every product is different & needs a specific approach) but it’s always better to start from something then from nothing. I hope that a few hints that I've prepared down below will help You to bring more value out of the Sprint Review!
Hints from Scrum Master:
- be sure that you are going to be a part of Sprint Review (as a developer, product owner, scrum master or any other stakeholder) and clarify that to other members who are not completely aware of what is purpose of that meeting (points 1-3) ;
- if you have some topics to discuss that are not directly connected to point’s 1-3 you should ask yourself if Sprint Review is the best opportunity to talk about those topics? (maybe other Scrum Event will suit better for those topics that you want to talk about or simply you have to create a separate meeting);
- timebox every Sprint Review! It pushes every meeting member to focus on things that are bringing most value.
For example 1h max:
- 15 min for presentation/live test of development done in last sprint ;
- 15 min for gathering feedback about development done in last sprint ;
- 30 min discussion and working on possible adjustments to Product Goal & reordering/creating Product Backlog Items;
- Scrum Team should be prepared enough to ask a non-technical Sprint Review member to demonstrate new features/ functionalities live during meeting;
- there is nothing wrong with preparing a pre-constructed agenda for a Sprint Review.
(just watch out to not copy/paste Product Backlog into the agenda & remember to leave the proper amount of time for discussion/making adjustments! )
- note feedback and any other valuable discussion points! (they may be a great foundation for Sprint Retrospective);
Sprint Planning
Sprint Planning purpose is to plan work to be done in order to obtain a Sprint Goal. That plan should be a result of a collaborative work session of the whole Scrum Team (and any other guests asked to participate in it if there is a need).
To bring most value out of Sprint Planning we have to ask ourselves and define answers to those 3 questions.
A) Why is this Sprint valuable?
Product Owner have to be prepared to start discussion about the direction in which product should be developed during the next sprint. Clearly defined Sprint Goal should be a result of that discussion.
B) What can be Done this Sprint?
Developers can now propose and discuss which backlog items they will bring into Sprint Backlog in order to obtain Sprint Goal.
C) How will the chosen work get done?
Specifying how work items will be changed into valuable solutions is solely the responsibility of Developers. (they are responsible for Sprint Backlog).
Sprint Planning demands attention and preparation from everyone involved in it. Common interest will emerge only with mutual understanding of the wider context of work planning (Why - What - How). We have to constantly remind ourself about it in order to bring as much value from Sprint Planning event as possible. Otherwise that meeting will degenerate into just “swiping” tasks between Product & Sprint Backlog which is a clear waste of time.
Take a look at some hints that I've prepared for You in order to prepare for a great Sprint Planning session
Hints from Scrum Master:
- be sure that you are going to be a part of Sprint Planning (as a developer, product owner, scrum master or any other stakeholder) and clarify that to other members who are not completely aware of what is purpose of that meeting (points A-B-C) ;
- if you have some topics to discuss that are not directly connected to point’s A-B-C you should ask yourself if Sprint Planning is the best opportunity to talk about those topics? (maybe other Scrum Event will suit better for those topics that you want to talk about or simply you have to create a separate meeting);
- timebox every Sprint Planning!
It pushes every meeting member to focus on things that are bringing most value. For example 90 min max:
- 15 min for presentation of next development ideas that are need to obtain Product Goal (Product Owner) ;
- 15 min for discussion about certain development idea in order to specify Sprint Goal (Scrum Team) ;
- 30 min for optimising a Sprint Backlog by choosing Product Backlog items that have to be developed in order to obtain Sprint Goal (Scrum Team);
- 30 min for discussion about how to turn Sprint Backlog items into valuable solution that will realize Sprint Goal. (Developers)
- it’s extremely important to give enough time to properly discuss & refine work items that will be assigned to the Sprint Backlog. Narrowing focus on defined Sprint Goal will allow you to spot & discuss any possible problems/blockers before development will even start!
- ask yourself if your Product Goal is a real thing ? (it should definitely exist!) Product Owner should have no problem with describing what are essential next steps needed to obtain that goal. That description will be a great place to start discussion about the next Sprint Goal.
- sometimes it will be beneficial to split the Sprint Planning session into two parts A)+B) / C) to erase some inconveniences.. For example if developers are in a different timezone than the rest of Scrum Team maybe they should be able to prepare a plan for development (point C) ) separately day after Sprint Planning (A+B) and share it with the Scrum Team in Sprint Backlog.
- there is nothing wrong with preparing a pre-constructed agenda for a Sprint Planning
(just watch out to not copy/paste Product Backlog into the agenda & remember to leave the proper amount of time for discussion/making adjustments! )
- note feedback and any other valuable discussion points! (they may be a great foundation for Sprint Retrospective);
If you want to know more about Agile frameworks in software development have a look at a few articles about them in our Knowledge Base !
