Types of Meetings in Scrum and Agile
In this post, we take a look at the various ways in which Scrum teams work together to create a working piece of software at the end of a Sprint.
Join the DZone community and get the full member experience.
Join For Freeintroduction
scrum has been in the game for over 20 years now, but despite that many of the companies that i am visiting are still struggling to understand the scrum framework and some of the companies or individuals have just recently heard about it.
for anyone who is just beginning the scrum journey, let me quickly summarize what scrum is about. scrum is focusing on discovering "what" is expected (e.g. the purpose) and understanding "why" something is expected. it's opposed to "how" we should implement the requirements. scrum is a framework , where there is a space for different tactics, which can be fitted into the context and individual case. you can think in the way that scrum is taking the best practices and scales them in the best way to fit into an individual organization.
scrum is supporting very simple, but yet very effective ideas, which are embracing teams to regularly check in on what they are doing, so that they can make sure they are heading in the right direction and that they are building something that people actually want. along with checking if the output is heading in the right direction, scrum also encourages teams to find ways that they can improve, not only the product or the service that they are building but also themselves, by asking how they could do something better and faster. what this basically means is that every so often, the team will stop and inspect what they are doing and how they might do it better. in scrum, this is referred to as the inspect and adapt cycle.
in this post, i will address 5 different types of meetings to be held during the sprint in order to utilize the scrum values, with open communication, collaboration, and efficiency. scrum meetings help teams to keep improving and to keep moving in the right direction.
ensuring the specific time-boxing for sprint meetings will secure the higher efficiency of the whole team and, of course, of the project itself.
with this cyclical process, the team will be able to communicate openly and honestly .
with a sprint length of one week , the time boxing for all meetings is estimated to be min 6h and max 11h and prior to holding the first meeting, the backlog should be well refined and prioritized. this is a very important aspect, as the people who are actually going to work to complete the backlog items should estimate how much effort it is going to take them to complete a particular work item.
sprint planning (2-4 hours for a 1-week sprint)
this is a first sprint meeting which should be held at the very beginning of the sprint , with a duration of 2-4 hours . the duration of the sprint planning meeting depends on the sprint length and for 1-week sprint, it should be between 2-4 hours.
usually, in sprint planning meetings , the whole team is present, including the product owner and the scrum master . in this meeting, the team will take the top items from the backlog and estimate or forecast how much they will deliver in the sprint and based on that they will gauge the team's velocity. once the team has run a couple of sprints, they will be able to understand the velocity of each past sprint, allowing them to work toward improving the velocity in future sprints. what this basically means is that the team will understand how many points they managed to deliver in past sprints and they will try to improve that number in future sprints.
goals of the meetings:
- agreed and verified about the pbis that will be delivered in the sprint.
- add all the team members' capacity, days off.
- assigned the pbis/ user stories to team members.
- planning individual tasks for all team members that respect the capacity for the sprint (green).
one of the very important principles of scrum is that the team should be committed to what they say they will complete in the sprint. this should not be changed and the team should really try hard to deliver what they have committed to deliver. to make this smooth, the teams usually use scrum boards , so that they can track their progress at any time.
stand-up meeting (15 minutes, every day)
this meeting is keeping the rhythm of the team in the right place, as this meeting should be held every day, at the same time, and same place. in the meeting, all team members should be present, including the scrum master. as the scrum teams are self-managed , the presence of scrum master is still preferable, but the meeting can sometimes also take place without the scrum master . the role of the scrum master in this meeting is usually to make sure that the team stays in the time boxing, that everyone gets the chance to speak and to remove any impediments coming the team's way.
goals of the meetings:
- what they did yesterday that can help the team to successfully deliver items from the sprint planning.
- what they are going to do today that will help the team to finish the sprint.
- are there any blocking points or impediments in their way?
with this meeting, the whole team will be able to have visibility into where exactly they are in delivering on the sprint goal and if everything is going in the direction to be delivered on time.
grooming (refinement session, 0.5 to 1 hours, 1-2 times per week)
as previously mentioned, the first grooming session should be held even before the sprint has begun, but preferably this is not the only grooming session that will be held. usually, and it's highly recommended, teams have another grooming session, somewhere in the middle of the sprint.
goals of the meetings:
- remove obsolete items (pbis/user stories) that are no longer needed.
- add new items, if this is necessary to deliver the sprint.
- refinement of the description or title.
- add initial or additional acceptance criteria.
- estimate the items.
- prioritize the items.
sprint review meeting at the end of the sprint (2-4 hours)
a sprint review, as the title implies, is held at the very end of the sprint. in many cases, you will hear people using the term " sprint demo," as this is actually what this meeting is about. the team will show the demos of their work, i.e. they will show exactly what they produced during the sprint.
however, one important aspect of the sprint review is that team should present only the working items that they have delivered. what does this mean? it means that the team will present or demo the work items that met the definition of done (dod) , which means that this item doesn't require any more work to complete it. it's ready to be delivered.
goals of the meetings:
- explain what items have been "done" and what has not been "done."
- discuss what went well during the sprint, what problems the team ran into, and how those problems were solved.
- demonstration of the functionality built during the sprint.
retrospective meeting at the end of the sprint (1 hour)
the goal of the sprint retrospective meeting is to discuss, openly, what went well and what didn't during the sprint, so that the team can, together, find better ways to meet the project's goals. here the team can discuss internal processes as well.
this meeting definitely requires trust and some maturity to discuss potential issues very openly. it's very important here for each team member to be aware of the responsibility of each individual, in order to be able to find the solutions that could make them perform better and faster.
during the sprint retrospective the team will address what they can:
- start doing.
- stop doing.
- continue doing.
conclusion
allscrum meetings are designed and considered in a way to help the teams to deliver faster and to solve any possible impediments coming their way, immediately. each meeting is an opportunity to improve the process and the performance in a great scope. this cycle of the meetings should be considered in each sprint cycle, considering the team's previous experience.
Published at DZone with permission of Mohamed Radwan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments