Originally posted here: dev.to account in Brazilian Portuguese. Post translated using ChatGPT.

Scrum Events: An Experience Report - Banner

A few weeks ago, some team members with limited exposure to agile methodologies asked me to share insights about the application of Scrum in my previous projects, focusing on how Scrum events were conducted.

I’ve noticed that sharing my positive experiences with teams applying Scrum is a recurring task, so I decided to write about it! :smiley:

Attention!

:warning: » This text will not discuss or present definitions. If you are interested in the definitions of the mentioned events, I recommend referring to the Scrum Guide.

And if you are just starting to study agility, it’s worth checking the Agile Manifesto.

Agility is not limited to Scrum.

Some practices presented in the text worked well in certain contexts. The challenges and choices made depend a lot on people and context. There is no one-size-fits-all solution (silver bullet) that works for all cases. « :warning:

Scrum Events

The following events are mentioned in the Scrum Guide and presented in the text:

In addition to the events mentioned in the Scrum Guide, the dynamics of Refinement will also be presented.

Sprint :runner:

:hourglass: 2 weeks

This is when the planned work is executed. To enhance agility in software development, we used automated tests (as living code documentation, providing confidence for the team to make necessary code changes), CI/CD (facilitating the software deployment process), and techniques such as pair programming. When unexpected tasks were requested, the “sprint goal” was used as a criterion for prioritizing between planned and unplanned items. When unplanned items were added to the “Sprint Backlog,” some planned item was deprioritized to avoid overburdening the team.

Sprint Planning :dart:

:date: After the retrospective

:hourglass: 2h-4h

During sprint planning sessions, refined items (ready to be developed in the next sprint) were reviewed. Items were pulled by the development team, according to the prioritization established in the product backlog, based on how much the team believed they could produce and commit to. To gain understanding and predictability about how much a team usually produces during a sprint, some teams used estimation systems and techniques: story points, T-shirt sizes (S, M, L), planning poker. At the end of each sprint planning session, the team defined the “sprint goal,” which helped the team organize and constantly inspect whether the actions taken during the sprint were contributing to goal achievement. The sprint goal definition was very useful for decision-making about item prioritization during the sprint as unexpected items emerged.

Daily Scrum :repeat:

:date: Daily

:hourglass: Up to 15 minutes

Daily stand-ups focused on planning for the next 24 hours and assessing whether we were continuously progressing toward the sprint goal. Impediments were declared, and people organized themselves to overcome blockages or notify whoever was necessary. When working with distributed teams, we often conducted the daily stand-up by looking at the tasks on the board, so we could identify invisible work (and record them using Jira), updating the board daily, checking which cards had been stalled for a long time. A daily cadence allowed the team to assess whether we were approaching the goal set in Sprint Planning, rather than realizing this only during the Review.

Sprint Review :gift:

:date: At the end of the sprint

:hourglass: 1h-2h

In this event, we presented the team’s deliveries and the value generated by the team, focusing on providing visibility into what was done and sharing knowledge among everyone. In addition to a “demo”, receiving feedback and insights from the team helped define improvements, changes, and the next steps that could be prioritized (resulting in updating the Product Backlog).

Sprint Retrospective :mega:

:date: After the sprint review

:hourglass: 1h-1h30

It constituted the continuous inspection phase of the cycle, an opportunity to note what was going well and we wanted to continue doing, as well as identify what wasn’t so great and we wanted to improve. The key point here was to extrapolate beyond individual points and develop action plans for the team, which would be followed and monitored. Formats varied from casual conversations to the classic use of the board (we used this online board). Some people liked accessing this site to learn new retrospective formats.

Refinement :microscope:

:date: Before planning

:hourglass: 1h

This event is not listed in the Scrum Guide, but some teams (especially those needing greater predictability) conducted it. The goal was to refine backlog items. Refinement could indicate that the item was not ready for implementation (possibly due to an unexpected prerequisite that would postpone the item to the next sprint) or that the item was too large and could be splitted into smaller parts. Refinement was also used as technical alignment among engineers who could discuss how the item would be implemented. For teams estimating tasks, it was a very useful meeting, as questions were anticipated, preventing planning sessions from becoming too lengthy.

How do you apply Scrum events?

In this text, I presented some experiences I had applying Scrum events in my professional daily life.

Do you apply it in a similar way? Completely differently? Did it seem interesting or wrong to you? Share your thoughts with us in the comments! :wink:

References