In the previously published intro to Scrum [the-basics-of-scrum-with-codetain-intro], we could take a close look at what work organisation at Codetain looks like. However, Sprint itself isn’t everything.
Scrum wouldn’t be complete without meetings.
Why are often meetings so important to developers, as well, and what do they actually look like?
Let’s get to the point now!
Scrum Meetings
I would say, that Scrum workflow is actually shaped by systematic meetings related to the sprint.
An important factor here is to keep all those meetings in proper shape and make an effort to show up on each. Otherwise, if you miss one or two, it’s dangerously easy to lose the track of what’s going on.
Such routine makes our work organised and that’s unbelievably important for a software company like Codetain.
Below, you can get to know more about all the kinds of Scrum meetings that are in our calendars*.
Sprint Planning
Sprint always starts with Sprint planning. During the sprint planning, the development team with the Product Owner are determining the Scope setting Goals for the Sprint. The initial commitment and goals established during the planning will be challenged at the end of the sprint.
What’s important here is to organise the sprint and the goals in such way that the stakeholders can actually see the progress.
That means that we have to deliver operational parts of software that can be proudly presented to the stakeholders. Constant progress is the key!
Also, it’s cool to see that the work we did in a previous sprint is giving real results.
Daily Scrum (Stand-up)
Another type of a meeting is Daily Scrum—also called Stand-up or Daily Scrum. Stand-ups are cyclical, as well, but they don’t need any particular organisation up front. The purpose of Daily stand-ups is to keep each other informed on what each member of the development team is doing.
This approach allows us to get the knowledge sharing constantly, catch up with possible delays quickly or define problems in time. Daily stand-ups should take no more than 10-15 minutes.
In a team where people are not used to participate in such often meetings, it might be overwhelming at the beginning. It’s important to emphasise that this particular meeting is suited strictly for development team to make sure they all are on the same page. Those are also helpful for the Product Owner who has to be up to date and react quickly in case of any disturbances or delays.
Grooming
Another important Scrum meeting is Grooming where tickets are created and estimated by the team. During those, developers and the Product Owner determine what needs to be done in a certain feature, create and estimate tickets (that is tasks for the current sprint and the amount of time and effort needed for each ticket).
Prepared tickets are later taken into the Sprint during Planning.
Grooming depends on the problems that need to be solved. This meeting might last quite long, even a few hours (it’s nice to divide Groominng into a smaller blocks in such case). The goal of this meeting is to investigate the problem deeply and prepare the workflow. This will allow to avoid misunderstandings and reduce significantly unexpected issues during the implementation.
After a countless number of groomings I’ve participated in, I’ve come up with a simple equation:
The better, more thorough grooming = the less issues during the implementation.
Sprint Review
The most important meeting, in my opinion, is Sprint Review. Review is the summary of Sprint. It always takes place after a Sprint where all the stakeholders, developers and other team members are analysing its course.
Goals are being challenged and the team is presenting what they achieved during the Sprint. This is why it’s so important to create goals in such way that it’s possible to show the progress clearly. A visible progress in meeting goals makes the stakeholders happy and Product Owner along with the Development team are satisfied from work they delivered.
Another point to discuss on Review is the sprint impacts—what went wrong, what was not finished in time, and what was added or removed from the sprint in the meantime.
However, the purpose of this meeting might be sometimes misunderstood. This is not a confession or a judgment day. It’s rather an opportunity to show the achievements proudly, to keep everyone on the same page, and discuss the project.
Retrospective
Last, but not least is Retrospective which takes place after Sprint Review. During Retrospective, the team alone is discussing what was good and what was wrong during the sprint.
This is the place to determine what can be improved, what was done exceptionally, what should be continued, and what should be definitely stopped.
From my experience, there’s always room for an improvement. I’ve never participated in so-called retro where there wouldn’t be anything to discuss. After retro, we can close the current sprint and start another one, and… all the described meetings start over again!
Conclusions
At the first impression it may seem overwhelming, but with the right attitude you can see that everything actually makes sense and is unbelievably helpful.
The key to understanding Scrum is understanding that those meetings are designed specifically to help the development team with their work.
If the tasks (tickets) are prepared better—more carefully, the lower the risk of missing an important (even if small) part needed to meet our goals.
Keep in mind that the earlier you find a problem or admit a mistake on the daily Stand-up, the more time you and your team will have to fix the bug! ; )
*Different Scrum teams, different customs! That is—every Scrum team can have a different Scrum routine. Some teams are doing Grooming on Plannings, some are doing Stand-ups every 2 days or even every week only. All the aspects can be determined by a particular project, stakeholders or even personal needs of team members. In the article, I’ve introduced you to our Scrum scheme at Codetain.