Scrum has events to inspect and adapt Artifacts
Continuous Inspection and Adaptation helps a team maximize the value of work done, and Events in Scrum provides this opportunity.
As written in Scrum Guide, Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required, failure to operate any events as prescribed results in lost opportunities to inspect and adapt.
What do Scrum events mean?
Scrum Events are time-boxed events, meaning maximum time is allocated, and the team can not extend it further. These events enable the team to inspect and adapt artifacts (product backlog, sprint backlog and increment. In addition, these events help review their performance and serve as a learning opportunity for the future. They can assess their working environment and come up with corrections wherever necessary.
Scrum has five formal Events:-
- Sprint Planning
- Daily Scrum
- Scrum Review
- Scrum Retrospective
A sprint is a container event, and all other events occur inside the Sprint.
Straight from the Scrum Guide — Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. Time-box helps avoid risks related to developing wrong solutions for complex adaptive problems. Although Sprint can get cancelled when a sprint goal becomes obsolete, the authority to cancel a sprint is vested with the Product Owner.
Sprint has a goal, and the sprint goal doesn’t change once set. Instead, it ensures that the team stay focused on a common yet specific goal. Once the Sprint starts, no changes are allowed in scope that can deviate from the sprint goal, degrading the quality and increasing risk. However, the scope may change within the sprint as long as it doesn’t impact the sprint goal negatively. Developers discuss with the product owner if changes are needed, like adding/removing work from the Sprint backlog.
The sprint serves two purposes
- Regular and continuous feedback loop by the client so the team can review and evaluate the changes
- Measure the team productivity and performance during the recurring period
Sprint planning is the first event within the sprint. In other words, sprint starts with sprint planning. The time-box for the sprint planning is 8 hours for a monthly sprint, and the whole scrum team participates.
As per Scrum Guide, The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
The entire discussion during the Sprint Planning meeting revolves around-
- Why is this sprint? Discussion helps establish the Sprint Goal for the sprint and the value that the scrum team will create in the sprint. Typically, the product owner presents business objectives for the sprint, and the Scrum Team discusses and craft possible sprint goals based on that.
- What is possible to deliver in this sprint? It isn’t easy to estimate what can be done within the sprint. Hence, developers use past performance such as velocity with current capacity and definition of Done to forecast the amount of work they can do. Developers pull the work from the product backlog to the sprint backlog in agreement with the product owner.
- How are we going to get the work done? Developers discuss the design approach and work involved in completing each selected product backlog item as per Definition of Done. Developers usually decompose Product Backlog items into smaller tasks that can get done within a day.
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
Daily Scrum meetings are key for ensuring tasks are being carried out efficiently to meet the sprint goal. In addition, daily scrum meetings, also known as “daily Stand-up meetings”, are common in various other practices. These meetings should not last longer than 15 minutes and usually include scrum team members (Product Owner, Scrum Master, Developers) — although developers must be there. Usually, time and place are consistent because consistency reduces complexity.
During daily Scrum, developers inspect progress made in the last 24 hours to meet the sprint goal and adapt for the next 24 hours. As a result, daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
A Sprint Review is a formal meeting held between the scrum team and stakeholders to inspect the sprint’s result, progress toward the Product Goal and adapt future work. It often results in discussing what and when to release product increment, adding new work to the product backlog, and discussing what to do next. The main objective of a Sprint Review is to achieve a potentially releasable product, also known as Product Increment. In other words, the outcome of the Sprint should be a working product. Then, participants decide what can be improved to get optimal value from these improvements in future products. The sprint review meeting gets scheduled within 4 hours at the end of each Sprint. Remember that it can also be shorter if your sprints last less than a month.
The Scrum Master works as a facilitator and makes sure everyone involved understands the rules and purpose of this meeting.
Sprint Retrospective is the last meeting of the sprint, and it can go up to 3 hours. The scope of improvement gets discussed regarding people & relations, processes & practices, and the Definition of Done. It can also be called a continuous improvement meeting to identify the potential errors and mistakes in the past and correct them.
It allows team members, including a product owner, a scrum master, and developers reflect on the actual product quality, finds deviations, and suggest scope for improvement. It is an inspect and adapt event for the Scrum team. It means that everyone should decide ‘what’ activities to stop doing, ‘which’ all things the team should be doing in the future and what ‘more’ should be done to improve the previous processes. A Scrum Master may facilitate the Sprint Retrospective meeting if needed or requested.
This brings us to the end of the Scrum Events. Keep reading and subscribe to my blogs for future reading.