Within Agile, Scrum is arguably the most widely adopted framework, as it is comprised of well-established practices that are easy to learn and relatively simple to use. Scrum events, still often referred to as Ceremonies, are the meetings defined in the Scrum framework to help teams plan, manage, and perform work in practicable amounts that support the ability to adjust to feedback and changing requirements. Scrum teams use these events because they work, however, the way teams use them is critical to the value they realize from them.
Whether you’re a Product Owner, Scrum Master, or team member it’s up to you to ensure the team is tailoring events to suit your team’s needs. This ability to modify your process is a key advantage that Scrum provides over traditional project management. After all, Scrum tells you what to do, not how to do it.
Have you or your team ever questioned how frequently you’re using certain events? Do you feel you’re getting what you need from your Scrum events? If not, it would be a good time to revisit the Agile Principles and consider this one: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly of reflecting on how to become more effective at regular intervals.”
Once you’ve reflected with your team, consider how to tune your process and adjust behavior accordingly. For example, do you feel your team is getting value out of a retrospective after every sprint? While Scrum calls for consistent retrospectives at this interval, when we’ve worked with 2-3 person teams, they simply don’t get the same value from a retrospective after a single sprint, as not much has changed within this small group.
While we still suggest using the recommended Scrum events, we encourage teams to regularly take a broader look to assess how Scrum events can be adjusted to make the biggest impacts. Simply following a methodology without challenging its effectiveness can limit your ability to optimize time spent, which leads to team apathy.
With many teams now working remotely, consider extending the 15-minute timebox to ensure enough time is available for team members to get on the conference call, align, and then have the “after party” where team members can ask questions and plan to align during the business day.
As team members may no longer be physically present to quickly pop-over to someone’s desk for a conversation, adding an extra 5-15 minutes has proven a good balance of time with driving concise and consistent alignment.
The standard two hours of sprint planning for each week of sprint is often too much time, particularly for the fast-paced work we typically do. Since we use velocity-driven planning, and mostly pre-plan during backlog refinement, scheduling 1.5 – 2 hours, and ending early if needed, has proven sufficient for our teams.
Many teams, especially smaller teams, don’t find value in having a retrospective after every sprint, as not enough time has elapsed to complete identified actionable items. In many cases, new opportunities to improve rarely arise in such a short time period.
Our teams plan for a retrospective after enough time has elapsed to check-in on actionable items while still maintaining focus on continuous improvement. We also encourage all team members to continually speak-up so the team can adjust “on-the-fly” without waiting until the end of a Sprint.
Many teams may not feel the need, nor gain value from demoing after every Sprint. Some Product Owners like to see incremental progress, even if it’s just code without a UI present. Some don’t see the value until there is something they can see.
Consider what’s valuable for your team and stakeholders. If the Product Owner or stakeholders don’t care to see a demo until a certain threshold or key milestone is met, consider holding them anyway if they help your team stay focused. This can also allow the team to practice demoing effectively. However, if the time is better spent on development, consider holding demos less often.
While not technically part of Scrum, backlog grooming is an extremely valuable practice to ensure your team has a relevant backlog that is ready for Sprint Planning. Consider whether the Product Owner or Scrum Master can get into the backlog in advance of this event to set priorities that will accelerate decision making and sprint planning.
While we acknowledge that Agile “purists” may disagree with some of these recommendations, consider how your team is performing and what team members’ perspectives are telling you. If you believe you can be more effective by adjusting how your team uses Scrum events, it can only help to talk about it with your team.
When you have an Agile mindset, it’s a benefit to try something – if it doesn’t work as expected, either adjust or revert to your team’s previous approach.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!