One of the most important rules for all the teams which work in Agile is:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

To be honest – I can stop here and don’t elaborate any further. This rule nicely summarises the point of all the face-to-face meetings and conversations. It allows you to clarify your thoughts and get the immediate feedback or questions before you start the development process or the next sprint.

Personally, I think that even a short video conversation may work in some cases. When you text with someone, it happens that you may not be understood. On the other side, there’s some point to  saying that our work measure is the product – not the hours spent on talking. Also, too many meetings organised in a short time can make it more difficult to put yourself in the process.

Nonetheless, some meetings must take place during the software development process. Scrum even introduces some fundamental meetings with limited time to make sure you won’t spend too much time talking. If you sum up the time you spent on meetings during one sprint – it shouldn’t exceed 14% of the sprint time (regardless of its duration). 

So once we agreed that there are some crucial meetings with time limits, now let’s move to the goals of these Scrum events and try to tell who needs to take part in these.

Scrum is the most commonly used framework for project management. Below, I’ll describe all the Scrum events as per their order during the Sprint. Let’s assume that the scope of the project is already set and all the most important tasks are on the top of your backlog. You can start your project with… sprint planning. It’s the first meeting during which you need to set the scope of the upcoming sprint.

Sprint planning

What is the goal of this meeting?

It is one of the core meetings during the Implementation phase. During this Scrum event, you need to set the scope of the work for the upcoming sprint. Product Owner presents priorities and the list of features which should be delivered. For the team itself – Planning is a meeting organised to make sure they understand the scope of the nearest sprint. You can use this event to set the order of tasks execution and perform decomposition of the tasks into the smaller ones if it’s necessary.

According to the TSH Approach (internal list of good Scrum practices used at The Software House), each User Story, in order to be clear and easy to implement, should be described using a Definition of Ready (DoR) and a Definition of Done (DoD). Definition of Ready is the sum of factors that must be met for the whole team to agree that the User Story is ready for implementation, i.e. it is properly identified and described in detail. Definition of Done explains when the User Story can be considered done. In practice, the DoD acts as a checklist for the Project Team, especially for the QA Engineers, letting them verify if the specific User Story was implemented correctly. 

During this meeting, there’s also some time for negotiation between the Product Owner and the Project Team regarding the number of tasks. You also set the goal of the sprint, i.e. the product that we are aiming to deliver at the end of the Sprint.

Who should take part in this meeting?

• Product Owner who sets priorities and the goal of the sprint;
• Scrum Master who makes sure that everyone agrees on the sprint’s scope;
• The development team to describe tasks in the sprint scope, decomposes tasks for the smaller ones, informs about dependencies and possibilities regarding the delivery of the proposed tasks.

Timebox

Up to 4 hours for the 2-week-long sprint; should take place only once during a single sprint.

Good practices

• Before the Planning, it’s good to set the priorities for the upcoming sprint with Product Owner,
• You should take team members availability into consideration: as well as any vacations, days off or other known delegations which may disturb the team’s work,
• Before the event, it’s good to read through the tasks which will be discussed during Planning.

Daily Scrum

What is the goal of this meeting?

Daily (also known as Daily Standup) is the Scrum event for the development team. Its main goals are to standardise the knowledge about the workload, plan its further development and identify any setbacks which can affect the Sprint’s Goal delivery.

The meeting also aims to monitor the progress of the work, so that in case of any problems or difficulties, you can react quickly or finally negotiate the scope of work with the Product Owner. During the Daily Scrum meeting, each member of the team should answer three questions: 

• What did you do yesterday?
• What are your tasks for today? 
• Are there any blockers for you to perform the tasks?

Who should take part in this meeting?

Daily Standup is the Scrum event for the whole Project Team. Product Owner can take part in dailies but his role should be limited to listening to what the team needs to discuss.

Timebox

15 minutes, everyday. 

Good practices

• Daily should be started by the person who has any blockers or setbacks, hardware issues or any other unplanned circumstances – to make sure the team knows about it as soon as possible.
• You should not focus on too many details of the task executed a day before.

Backlog Refinement

What is the goal of this meeting?

Backlog refinement is a Scrum event taking place in the middle of each Sprint. The main goals for this event are:

• Discussing and detailing the tasks from the backlog,
• Decomposing the existing element,
• Adding some new elements to the backlog,
• Adding the acceptance criteria to the tasks,
• Adding the estimations to the tasks by the development team,
• Ordering the registry elements – setting the priorities for the upcoming sprints.

It’s a pretty neuralgic Scrum event which has an impact on the nearest sprint. You should discuss the tasks for 1-2 upcoming sprints during this meeting. Thanks to the regular Refinement, you lower the risk of misunderstandings and save some of the time dedicated to task analysis during the development process. The effect of a good Refinement meeting is a prioritised Backlog, as well as decomposed estimated tasks which are described as per DoR and DoD.

Who should take part in this meeting?

First and foremost – it’s the event which must be attended by the Product Owner. This is the person who has the greatest knowledge about the priorities and can answer the questions of the development team. The team should obviously take part in the meeting as well. Their responsibility is to decompose the tasks and agree on the acceptance criteria with the Product Owner. Not always all the team members must be present during Refinement. There’s a variation of this meeting called Three Amigos. You invite those parties to that event (and they should answer the following questions):

• The business representative, to answer “What problem are we trying to solve?”
• Development team, to answer “How might we build a solution to solve that problem?”
• Testing team, to answer “What about this issue, what could possibly happen?”

Timebox

This meeting should take more than 10% of the sprint time. It equals to about 3,5h per one-week Sprint. Refinement is a pretty flexible kind of meeting. It’s good to divide this meeting into at least two parts. I recommend performing Backlog Refinement on a daily basis. In my team, we stay 15 minutes longer after Daily Scrum to discuss one, already set task. Then, we meet at a longer meeting where we estimate these tasks.

Good practices

• Setting priorities for at most two weeks forward with the Product Owner,
• Discussing these tasks during Refinement,
• The meeting shouldn’t take more than 90 minutes,
• Sending the agenda with the tasks list to all the team members to make sure that everyone is on the same page with what will be discussed before the meeting,
• In some bigger teams, it’s good to divide Refinement into two parts – the first in a limited squad (with the leaders of the frontend, backend and QA teams), the second with the full squad,
• It’s good to discuss one task per day, but it’s also important for the team to add the comments or sub-tasks to the backlog after the meeting.

Sprint Review

What is the goal of this meeting?

One of the two meetings held at the end of every Sprint. During the Sprint Review, the Project Team organizes a demo – to present the work done during the Sprint and whether the planned tasks on Sprint Planning were delivered according to the client’s requirements. 

During this Scrum event, the Product Owner accepts or declines elements of the backlog delivered by the team. It’s time to provide feedback too.

Who should take part in this meeting?

The Product Owner and the development team are obligatory. But all the project’s stakeholders are welcome. 

Timebox

Up to 2 hours in the two-week-long Sprint. Once per Sprint.

Good practices

• It’s good to inform the Product Owner about the task statuses and present the overview of the agenda before the meeting,
• The meeting is not only about presenting the tasks but also discussing the whole Sprint and all the tasks (not only completed ones),
• It’s good to present the tasks as per the final functionalities which will be used by the end-user subsequently.

Retrospective

What is the goal of this meeting?

As we can read in Scrum Guide: “Retrospective meeting is the opportunity for the Scrum team to inspect their work and prepare the improvements plan to be implemented during the upcoming Sprint.

Its main goal is to improve the development process during the next Sprints. There is always something that can be improved, so the Project Team analyses the total cooperation during the previous Sprint. During this meeting, each participant should comment on things that they think went well and that need improvement. At the end of the meeting, the Project Team should decide if any improvements are needed, and choose a way to achieve better cooperation in the next Sprint.

Who should take part in this meeting?

Everyone involved in the project should take part in the Retrospective. At times, it’s also good to invite the Product Owner for such a meeting. Naturally, some team members may be reluctant to talk about some internal problems within a team in front of the Product Owner, but on the other hand – the cooperation between the Product Owner and the Development Team often needs some improvements too. I prefer the solution in which the Product Owner is invited for every other Retrospective or for each Retrospective but only for a part of the meeting. Thanks to that,you can talk to the Product Owner and also discuss all the internal issues within the team.

Timebox

This meeting should last up to 1,5 hour in the two-week-long Sprint. Once per Sprint. 

Good practices

• Using tools such as FunRetro – it helps writing down all the successes and setbacks to draw some conclusions and decide on some further actions to improve the process and verify it on the next Retrospective,
• It’s good to make this Scrum event a bit casual so everyone feels free to present their opinion,
• Sometimes it helps to go out for the Retrospective – for example for a team dinner, 
• It’s good to change the form of Retrospective from time to time to keep it interesting,
• You can also introduce a comment box for the team members – they can put their cards with comments during the Sprint and then – discuss all the comments during the Retrospective.

Summary

The retrospective closes the whole Sprint cycle. The next Sprint starts during Sprint Planning. The Scrum events presented above are very important parts of the project. Resigning from any of them may cause some issues within a project or even result in the team not being able to deliver the product on time or in the form the client wanted.

As mentioned before, in Agile project management, the basis for successful cooperation is face-to-face discussion. During the current circumstances of the pandemic, the majority of these events take place online. It’s important to make sure that everyone has their camera on during the events.

It’s also important to keep the chronology and timeframes for all these meetings. Thanks to that, everything should go smoothly, your team will benefit from the events and the final product will be delivered on time.