Scrum Sprint Events: What Are and Why Do They Turn Ideas into Value?
Since the Scrum Sprint is the beating heart of the Scrum Methodology, where the idea becomes value, I decided to turn my attention to the events that make it up and that are functional to achieving the Product Goal. These are my promises of intent before starting:
- Review what Sprint Scrum events are (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective).
- Identify the functional and effective focuses for optimal use of Sprints in Scrum.
What is the Scrum Sprint: focus on Empiricism
Each Scrum Sprint can be considered a short project, with a precise duration and objectives that can be inspected and measured. Here are the points I fix well to create a valuable Scrum Sprint:
- The average duration of the Sprint in Scrum is about 2,4 weeks (from a minimum of 1 week to a maximum of 4 weeks).
- I can design shorter sprints to support development team learning cycles and focus efforts in a shorter time frame.
- The Product Backlog is not immutable but can be inspected and perfected, as needed, in order to gradually adapt to the Product Goal.
- After each Sprint the next one begins.
Now all that remains is to recall as input the basic foundation of Scrum Theory, which I can use before starting the Scrum events. The answer is univocal: the Principle of Empiricism teaches how to “learn by doing” in complex processes, where it is not possible to know in advance what will happen.
Since in complex jobs the initial level of information is usually low and based on hypotheses, I will not be able to plan either in detail or in advance. But I will be able to learn as I do and then re-enter the information obtained in the process.
LBD (Learning By Doing) – My focus therefore is not on building a perfect plan, but on the results I get so that I will be able to make strategic and forward-looking decisions based on what has already happened.
Sprint Planning: focus on Time
I am ready to start the Scrum Sprint and put in place the first event: the planning of the Sprint. First of all, I recall what Sprint Planning is for, that is, to define what can be released and how the work process will take place. Then I can decide:
- How long the timebox will last;
- The starting point;
- The goal.
I do this in collaboration with the entire Scrum Team which operates as a single body within the entire Scrum Sprint.
Scrum Sprint: Timeboxing
Time is my ally and my judge in planning the Scrum Sprint. I know I need to set a time limit for this event, called Timeboxing. I also know that during the Sprint no one is left alone and that decisions and reviews are always shared.
In Sprint Planning, it is the Scrum Master’s responsibility to verify that the planning meeting respects the set maximum time. On the other hand, since there is no minimum time, if the Team quickly agrees and is satisfied before the timebox expires, the event ends automatically.
How long does Sprint Planning last?
Scrum Sprint planning should constrain no more than two hours for each team work week. For example, for a Sprint lasting 2 weeks, Sprint Planning will total a maximum of 4 hours (2 hours maximum per week).
Sprint Scrum: focus on Objective during the planning
During Sprint Planning I am very clear that I must not lose sight of the final objective of the event: to create a necessary and sufficient action plan to get to the next Sprint. To do this I have to avoid getting bogged down in details.
Since, regardless of the role (Developer, Product Owner, Scrum Master), I act as an integral part of the Scrum Development Team I am aware that the plan will serve to raise the concentration of the whole team and to stimulate self-organization, while acting as a containment net to avoid giving in to distractions.
How do I optimize Sprint Planning?
The Scrum framework encourages the development team to sprint to deliver a valuable product, taking opportunities from the scrum process to constantly learn and improve.
I keep this concept in mind and instead of planning every minute of the Scrum Sprint, I focus on the goal: this will motivate the team to find intelligent solutions and alternative ideas to cross the finish line, clearly defining both the result and the methods of action. In this regard, I make sure that the Sprint Backlog is ordered and shared, in such a way as to allow the Scrum Team to achieve the primary goal of Sprint Planning: to define the what (the Sprint Goal) and the how (the practical process).
In any case, I focus, in the first part of Sprint Planning, on the results rather than on each single work task: I focus on the objective and leave the details in the background, including the logical concatenation of the tasks, the responsibility of the work and the quantification of the necessary time, which in any case I never lose sight of, thanks to the Sprint Backlog.
The Sprint Backlog defines elements that can be designed thinking about a single result, while the Sprint Goal describes at an advanced level the final goal of the work process over a predetermined time frame.
Daily Scrum: focus on Adaptation
The Scrum Guide (updated in 2020) is very specific on the dual purpose of the Daily Scrum:
- Inspection function for progress towards the Sprint Goal
- Adjustment function of the next scheduled job
The adjustment of the planned work is implemented by adapting the Sprint Backlog to the priority needs and contingent needs. In other words, we speak of adaptive solutions precisely to indicate this flexibility of the Sprint Backlog both in relation to the state of affairs and (above all!) In relation to the work to be carried out.
Ethology teaches us that living beings develop adaptability to improve their opportunities and to respond to threats.
How does the Daily Scrum take place?
The daily Scrum Sprint event lasts 15 minutes and involves all the Developers of the Team. Developers focus on understanding how to work together to achieve the Sprint Goal and create the relevant Increment by the established end of the Sprint. Specifically, this is the basic structure of a Daily Scrum:
- Duration: 15 minutes
- Cadence: 24 hours away
- Participants: Developers of the Scrum Team
- Mission: Optimize the odds of the Scrum Team reaching the Sprint Goal
Developers use the Daily Scrum to inspect work progress towards the Sprint Goal and to highlight any obstacles along the scrum process leading to the next step. There are no imposed techniques or established methods: Developers have a free hand, as long as they focus on progress towards the Sprint Goal and produce a feasible plan for the next working day.
I can summarize the roles and development of the Daily Sprint Scrum as follows:
- Developers are responsible for the Daily Scrum.
- If the Product Owner or the Scrum Master are an operative part of the Sprint Backlog items they also participate as Developers.
- The Scrum Master is responsible for ensuring that the meeting takes place and is kept within the 15-minute time-box.
- If other team members outside the Scrum Team are present, the Scrum Master ensures that they do not interrupt the meeting.
Sprint Review: Focus on Inspection
The inspection already present in the Daily Scrum becomes an essential part of the next event: the Sprint Review. Compared to the inspection of the daily meeting, however, the one that takes place in the penultimate event of the Scrum Sprint brings two distinctive elements to the field:
- Stakeholders
- Product Owner
I will not dwell on who these figures are (for the difference between Product Manager and Product Owner, I refer you here), but rather on the relationships that are created between the two new agents and the Team engaged in the Sprint Scrum.
It is the responsibility of the Product Owner to identify key Stakeholders and invite them to review the Scrum Sprint.
The group presents the results of the work done to the Stakeholders and together they examine what has been done (or what has not been done), in relation to the progress towards the Product Goal and how the facts have changed the process.
It is the responsibility of the Product Owner to discuss the Product Backlog in its current state and plan delivery dates and any possible and probable milestones based on the progress.
Based on the empirical information gathered, all participants collaborate in deciding what to do next, modifying the Product Backlog in case new satisfactory opportunities are identified. The end result is a revised Product Backlog outlining the items eligible for the next Sprint Product Backlog.
How does the Sprint Review take place?
Before moving on to focus on the latest Scrum Sprint event, I summarized the basic structure of the Sprint Review:
- Duration: 4 hours for a one month Sprint
- Participants: Scrum Team and all people invited by the Product Owner
- Mission: Provide valid input for the next Sprint Planning session
Retrospective Sprint Scrum: focus on Improvement
The Sprint Retrospective is the final act of the Sprint and an opportunity to reflect on quality and effectiveness. Once the review is complete and before the next planning, the entire Scrum Team (Developers, Scrum Master, and Product Owner) carries out a targeted inspection on the following factors:
- People
- Human Relationship
- Workflows
- Tools and Methods
- Definition of Done
Depending on the responsibility, different roles are played in the meeting.
The full Scrum Team discusses what went well and what, conversely, went wrong during the Sprint. Regarding the problems, they are first identified and then explored in detail, to understand how these assumptions of the error have been (or have not been) resolved. As for the useful and effective changes and impactful improvements, they are immediately placed at the center of the discussion and attention of the group. The most valuable items can be added to the Sprint Backlog of the following Sprint if necessary.
It is the Scrum Master’s job to encourage the entire Scrum Team to improve the work process and practical techniques to make it not only more effective in the next Sprint but also more fun and engaging.
In the Sprint Retrospective, the Scrum Team values every tool used and every method applied to increase product quality by improving the work process and communication flows. The Scrum Team may decide to adapt the definition of “Done” if this is appropriate and does not conflict with either product standards or those of the organization.
How is the Sprint Retrospective done?
The Sprint Scrum in Agile Methodology – In compliance with the principles of simplification, self-management, and shared responsibility – leaves free choice on the modality of the Scrum Retrospective. With a view to continuous improvement, however, I verified that the “Start-Stop-Continue” scheme is the one with the highest impact in encouraging the team to progress towards quality objectives.
- Duration: maximum 3 hours for a month-long Sprint (less for short-duration Sprints)
- Participants: Full Scrum Team
- Mission: At the end of the Sprint Retrospective, the Scrum Team should have identified improvements that can be implemented in the next Sprint.
The identification and implementation of improvements for the following Sprint show in fact that the Scrum Team was able to adapt to the inspection. This is made possible by the discussion and concentration of the team on the following topics:
- What went smoothly
- What could be improved in the next Sprint
- How we want to strive to improve
The Scrum Sprint Retrospective is the best opportunity for the entire team to inspect themselves and their work and to plan improvement actions to be put into practice in the Sprint to come.
With the purposeful momentum towards process and people improvement, the Scrum Sprint starts over from the first event: planning. Thus all the actors and the complete Scrum Team return to the scene: the Product Owner who defines the value sought, the Developers who try to understand if and how they can reach the Sprint Goal and the Scrum Master who supports and encourages the team, monitors events and actively participates in them.