Scrum Events with pictures

[#1]

This is the third part of a series where I summarise what I learnt by attending a Scrum.org course, studying, and passing an exam to become a Professional Scrum Master in December 2019. Scrum Roles with pictures started this series and was followed by Scrum Artifacts with pictures. After this article there will be at least one more in the series reviewing some of the keywords and phrases frequently used when talking about Agile and Scrum but are not part of The Scrum Guide.

There are five Scrum Events recognised in Scrum:

• Daily Scrum
• Sprint Planning
• Sprint Review
• Sprint Retrospective
• Sprint

Agile ways of working emphasis "just enough" planning so all these different events can seem a lot to introduce. Once these events have been implemented well, the different focus of each meeting and the amount of time saved in ad hoc planning during sprints becomes apparent.

Daily Scrum 

Are Daily Scrums the same as Stand-up Meetings? Surprisingly, no though they both are meetings that happen at the same place and time daily with an expected maximum length of 15 minutes. Stand-up Meeting guides typically emphasis the need to be physically standing (see the Atlassian Playbook and Wikipedia) and focus of people giving progress updates quickly. I hope it is a joke that some teams have taken this a step further - Planking Meetings:

Another myth is that the Daily Scrum is lead by the Scrum Master. The Scum Master is actually an optional attendee and their responsibility is limited to making sure the meeting takes place (i.e. agreeing/identifying the time and place and sending out meeting invites). If the meeting is not happening as scheduled soft penalties may be applied (as per the team charter/working agreement) and education about the value of these meetings needs to be shared with the team or with individuals who are being resistant. 

Daily Scrums are owned by the Development Team and are a chance for team members to get on the same page and agree on a strategy for the next 24 hours of the sprint. This is also a good time to raise any impediments (problems outside of the ability of the Development Team to solve) to the Scrum Master. As a self-managing team, the Development Team should work together to solve the unpredictable and complex issues that are inherent in development.

Sprint Planning 

Daily Scrums focus on what is needed in the next day to achieve the sprint goal. Sprint Planning takes a wider view - the next 1-2 sprints. This is where the product backlog items are turned into sprint backlog items; breaking user stories down into tasks, agreeing on estimates (usually), and when the Development Team selects how much work they can do in the upcoming sprint.

Development is rarely as simple as writing some lines of code, testing it, then releasing the code. Sprint Planning allows the Scrum Team to work together so the Development Team can create a prioritised sprint backlog where they know the what, who, and how for each of the tasks. This can include dedicated time for researching, working on technical debt, as well as identifying what the next done increment is expected to include.

Sprint Planning is helped by having a well-ordered Product Backlog even though Backlog Refinement is not one of the mandatory Scrum Events.

Sprint Review 

Decisions based on observation and experimentation (empirical process) rather than detailed advanced planning is fundamental to the Scrum framework. Sprint Reviews are opportunities to use the 3 components of empiricism - transparency, inspection, and adaptation - to confirm, and re-align if necessary, what is being delivered is what is desired. 

A sprint review meeting is not a sign-off meeting or a demonstration of a finished iteration. Sprint Reviews are an opportunity for collaboration between stakeholders and the Development Team. Ideally, stakeholders who will be the end-users of the product, are able to interact with the done increment directly though user acceptance testing should be completed separately.

The following was described so well on a ScrumDesk.com blog I am quoting it:

Five tips how to demonstrate functionality 

1. Describe the problem, pain or job, or gain.
2. Mention who is a persona doing that job, having the pain.
3. Explain what it is expected as the correct result.
4. Demonstrate the functionality. Simply, straightforward, without technology words.
5. Ask for feedback.

Keep the timing according to the agenda. ScrumMaster is responsible for that. ScrumMaster moderates the sprint review. The Product Owner is a leader of the meeting. She represents the team, the head of the development body. Team members demonstrate functionality.

Of course it is important for the Development Team to remember:

Sprint Retrospective

This event is a chance to focus on the "how" rather than the "what" of the Scrum Teams work. 

There is a lot of room for creativity and fun here. There are even websites that will randomly generate an agenda for your Sprint Retrospective. Here are a few places to get ideas so your Sprint Retrospectives never need to become stale or repetitive.

• Random Retros uses the format Check-in, Conversation Starter, and Check-out with 22 formats at the time of writing this article. 
• Retromat has a 5-part format Set the Stage, Gather Data, Generate Insight, Decide What to Do, and Close the Retro - with over 11 million possible combinations of the 139 activities available.
• Fun Retrospectives ups the ante to a 7-part format - Context, Prime Directive, Energiser, Check-in, Main Course, Filtering, and Check-out with many sample activities.

Sprint retrospectives are action-oriented and future-facing. The Scrum Team members need to be courageous, be open, have focus, show respect, and have commitment to the team (the Scrum Values) otherwise the game-changing topics are unlikely to be discussed critically and meaningful change is unlikely to happen. 

Sprint 

When listing Scrum Events it is surprisingly easy to forget to mention the Sprint itself. Unlike other events with maximum length time-boxing, the length of the sprint is fixed. Only the Product Owner can cancel a sprint but this is very uncommon and is very disruptive. For this reason, the length of a sprint should consider the length of time the team can plan for without expecting significant change in the sprint goal and/or company direction.

If this happens regularly you may need shorter sprints.

The most talked about aspect of Sprints seems to be the length. Just like the recommended length of sprints, the article lengths vary from the delightfully detailed question-driven article The Key To Sprint Success? Your Sprint Structure, to Software Yoga's strong but flexible recommendation Sprint length – short or long?, though to Effective Agile's short answer (with elaboration) - Let the Development Team decide. Anecdotally, 2 week sprints are the most common.

TLDR: 

The Scrum Events are all important and their durations (except Daily Scrum) are proportional to the Sprint length.

[Hannah McKenzie]

Excellent write-up @Kat Warner!