Scrum’s all about teamwork. And without the team meeting (online or offline), making decisions together, evaluating as well as praising, it simply won’t work. That’s why the core of the Scrum methodology is a series of recurring events. Years of practice have taught us how to make the most of each of them. It’s mainly about using the right tools and asking the right questions.
An electrician can also come to planning
The first of the meetings is sprint planning. The entire team, including the Scrum Master, participates and it lasts a maximum of 8 hours in a monthly sprint. On our projects, it takes somewhere between 2 and 4 hours. The purpose of this meeting is to listen to the Product Owner and define the sprint goal together. Subsequently, the planning goes into the hands of the development team, who decides what they’re able to deliver as part of the sprint. The result of the event is a work plan for the next sprint.
The team can invite other people to planning to help them understand the context needed to achieve the sprint goals and provide advice. Anyone who understands the project and what it’s supposed to bring to the client – whether it is an accountant, an architect or an electrician – can be invited to the meeting.
When planning, we like to use the so-called User stories, into which each function within the sprint is divided. When creating user stories, we use the WHO/WHAT/WHY tool. This helps us to clearly define the criteria that ultimately lead to a successful completion of the task.
A user story may look like this: As a teacher (who), I want the Edupage application to display all news on the website (what), so that parents and students are regularly informed (why).
Daily stand up for a successful sprint to the finish
The result of each planned sprint is to meet the set sprint goal and increase the value for the customer. It’s good to visualize its progress through a suitable tool – in bart, we use Gitlab, Jira, AzureDevOps or a plain whiteboard.
Each team member should have their tasks updated on a daily basis. This is important so that everyone on the team knows what the status of the individual tasks is and to maintain transparency.
The team reminds itself daily of fulfilling the sprint goal at stand-up (daily) meetings. These take a maximum of 15 minutes. There’s also room for mutual consultation in case of issues and suggestions for improvement.
The most common stand-up practice is answering 3 questions:
- What did I do yesterday?
- What am I going to do today?
- Do I have any problems that will affect the sprint goal?
Stand-up, however, shouldn’t only fulfill the task of vocalising the status, but also answer the question whether we’re approaching the goal of the sprint, and if not, how we need to reschedule the work between people.
Development in a team also means that even if tasks of one team member are finished, but tasks of other team members are not, even this one member, who already has “done their job”, continues to work and tries to help the colleagues. Therefore, it isn’t uncommon for tasks to be rescheduled during stand-ups and they’re distributed among people based on the current situation. We follow the rule that it’s always better to have 3 out of 5 scheduled things delivered than to have all 5 in progress and none completed.
Evaluation also requires speaking skills
At the end of the sprint, during its evaluation (sprint review), the finished tasks are presented to the client but also to everyone who is involved in the project and was invited to the meeting. So it includes the product owner, investors, suppliers, the client himself or even a sample of customers sent to the meeting by the client. The evaluation takes a maximum of 4 hours.
At this meeting, the team receives feedback and at the same time, it’s assessed how the sprint goal has been met, new features are approved, additional requirements are defined and finished parts are presented. Here the client directly sees the increase in value of the product. This is the only meeting where the team can meet with the client and see a “live” response to the product they are developing.
Knowing how to present yourselves needs a certain dose of extroversion and speaking skills. If a member lacks these characteristics, they may ask a more eloquent colleague to present their task.
Retrospective to express every opinion
The last regular meeting is a maximum of 3-hours-long retrospective. It can take many forms, but its intention is always the same – to allow each team member to express their opinion and say what’s good and what could be changed/improved in the next sprint. At the same time, it’s about self-reflection, praise among the team members and mutual motivation.
The content of the retrospective isn’t discussed across teams, it’s an internal meeting within the team. The important thing is that no one blames anyone during the retrospective. If something goes wrong, the whole team takes responsibility for it and together they look for opportunities for improvement.
A retrospective should always end positively. Even the negative things that are discussed here are necessary to bring about change that is positive in the long term.
The entire team participates in the retrospective and everyone has the space to bring suggestions for improvements. However, we shouldn’t forget the more introverted members, who probably won’t be comfortable talking out loud, and therefore it’s advisable to consider using some of the online forms of a retrospective, for example retrotool.io. Here it’s possible to create “bulletin boards” where members can write their opinions anonymously.
Types of bulletin boards that we like to use and rotate on a regular basis so that the retrospective is not monotonous:
- Mad | Sad | Glad
- Liked | Learned | Lacked
- Start | Stop | Continue
- Fast | Furious | Fearful | Looking Forward
- Kudos | Went well | Could be improved
- What went well | What could be improved
- Superpowers | Kryptonite
- Strengths | Weaknesses | Opportunities | Threats
- Drop | Add | Keep | Improve
- Pride & Joy | Personal improvements | Team improvements
Finally, all proposals for changes that are mentioned during a retrospective are written down in the form of action items and gradually implemented. We register them in Confluence, Gitlab or directly in the online retrospective tool. At the beginning of each subsequent team retrospective at the latest, the incorporation of action items is checked.
None of them are the best – or are they all the best?
It’s very important to carry out all 4 meetings as part of the development. Each of them is the most important one for a different team member. The product owner needs to explain their requirements and make sure that the team understands them. The client, on the other hand, wants to hear the results and therefore the evaluation is the most decisive for them. The development team must consult daily and share information about progress, so for them, stand-up is necessary. Well, the scrum master probably considers the retrospective to be the most important one, where they can motivate people to achieve the best results possible.
Properly set and effectively implemented meetings form solid pillars on which every Scrum development is based. We can’t even imagine our work without them.
