Event Number 1: The Sprint. A sprint produces incremental changes or improvements to a product or service. All sprints in a project have the same duration, usually two weeks or one month. Sprint durations remain unchanged. The next Sprint begins immediately after the previous one ends.
The objective of a sprint is called a sprint goal. Teams develop increments based on sprint goals. Planning is done, of course, during sprint planning. The Sprint’s scope is modified depending on what the team and product owner learn from the project. A sprint involves defining what needs to be built and designed and its corresponding plan. This plan will guide the development of subsequent product increments.
If the sprint goal becomes obsolete, the Sprint should be cancelled. This might occur if the organization changes direction or market or technology conditions change. The product owner can only cancel a sprint, though others may influence this decision. Due to sprints’ short duration, terminating them rarely makes sense. It is very rare for sprints to be cancelled because they consume resources since they require reorganization into another sprint. If a sprint is cancelled, and part of the work produced during the Sprint is potentially releasable, the product owner acknowledges the cancellation and accepts. All incomplete sprint backlog items are returned to the product backlog.
Event Number 2: Sprint Planning. Sprint backlogs are created from product backlogs. Sprint planning is where we create the sprint backlog. Domain experts who can answer questions are welcome to attend. Scrum masters help team members identify constraints that prevent them from committing to sprint goals. Teams must be more flexible in their commitments based on past performance. Sprint backlogs are completed once sprint planning concludes. Sprints track estimated remaining time, not actual spent time. For example, it may take the team twice as long to debug and tune because of their lack of experience. Consistency will improve as more is learned.
Sprint goals are discussed after that. Product owners must attend this meeting because they determine the depth and breadth of a sprint goal. Disciplines estimate their work; for example, coders estimate tasks together. Estimates are based on hours, assuming no interruptions. Due to interruptions, problems, or conversations, eight-hour tasks may take more than one day. More extensive tasks are more challenging to estimate accurately. Large tasks cannot be broken down into smaller ones within 16 hours. The 16-hour limit is reasonable for breaking down large tasks into smaller ones. Sometimes, a team cannot divide a task lasting over 16 hours into smaller segments for which a placeholder task will be created. Estimated hours are calculated by breaking down each PBI into tasks. Based on this total, sprint backlog hours are compared. A new PBI is completed according to the sprint backlog. Specialities must match capacity. PBIs exceeding sprint backlogs are not committed.
In this case, there are three options. Option One: Change the PBI to a smaller one. Divide the original PBI into smaller ones. Option Two: Remove an item before adding another. Option Three: Teams and product owners can discuss the most appropriate approach.
During sprints, forgotten tasks are common. Last-minute sprint items should be avoided. No additional feature is necessary in a short time (one or two days). The following segments exemplify a checklist a scrum should remember when planning a sprint.
Scrum Alliance provided this checklist.
Stage 1: Pre-sprint Planning Meeting. One: Clear up what is in the doing/sprint backlog. Two: Move any items that need to be updated.
Stage 2: Sprint Planning Checklist One: Capacity – Who is taking time off this Sprint? Does anyone need space to work on product backlog items (learn, attend, grow)? Two: Sprint Goal: Review the goal and allow questions and clarifications Three: If using velocity, review previous velocity and estimated velocity. Four: Include any action items from the previous retrospective. Five: Do we need space to clean up bugs? If so, what is the priority (compared to other work)? Six: What could you work on, OR do you want to learn more about the sprint goal? Seven: Refine and Detail; it takes approximately 15 minutes to add acceptance criteria and tasks/checklist items, including description, order and size. Eight: Pull items over from the product backlog — one at a time asking about capacity, clarifying tasks, who is doing what, and splitting cards if they seem too big. Nine: Dependency check – is anyone needed from another team? If so, send them a message and see if they can help. Ten: What else do you think needs to be pulled in? Eleven: Double check capacity — if you are using velocity techniques to forecast your Sprint, pause as you get close to your team’s reasonable velocity and ask, “Have we committed to too much for this sprint?” Twelve: Continue for those that still have space. Thirteen: Make sure the team’s work aligns with the sprint goal, allowing them to focus on one goal.
Stage 3: Post-sprint planning. Ensure there is time scheduled/planned for sprint review preparation work
Event Number 3: The Daily Scrum. Daily scrum meetings are held daily. Teams new to Scrum often need to pay more attention to daily scrums. Daily scrum meetings have three purposes: Syncing efforts among team members. Keep the sprint goal in mind and commit to work by the end of the day. Identify and address any impediments. To make sure everyone is on the same page. During this meeting, each member must present their pain points so that solutions can be addressed afterwards. Daily scrums are 15-minute time-boxed meetings attended by all team members. The meeting is open-ended and nobody can sit down, which reinforces the idea that this is a brief huddle. Getting to the point is essential in a daily scrum.
Team members answer these three questions in a circle:
“What have I done since the previous daily scrum?” Describe anything related to the sprint goal or obstacles related to it.
“What am I aiming to accomplish between now and the next daily scrum?” Each team member describes their plan for the next daily scrum. Team members should mention any work not related to the goal.
“What are the problems or impediments slowing me down?” An impediment is anything that prevents us from delivering what we promise.
We don’t solve problems in daily scrum. To prevent protracted and ineffective daily scrums, the Scrum Master must keep side conversations to a minimum.
Throughout the day, problems are solved. The following list has been contributed by Anna Rudat, a checklist scrum masters should consider when facilitating daily scrums:
One: Does it happen daily?
Two: Does it always happen at the same time?
Three: Is it always at the same place?
Four: Is it an actual exchange for developers?
Five: Does it take 15 minutes to complete?
Six: Does it include active participation by all involved?
Seven: Does it allow us to discuss progress towards the sprint goal?
Eight: Is an action plan coordinated for the day?
Nine: Does everyone know what they are working on?
Ten: Are people actively prepared to discuss their contributions to the daily?
Eleven: Do the team get caught up in details? If so, stop it
Twelve: Are the impediments discussed? Is there a plan to solve it?
Thirteen: Does the team find the meeting boring?
Fourteen: Does it clarify who works on what?
Event Number 4: Sprint Review
Every Sprint ends with a sprint review. At the Sprint Review, an increment is presented for review.
Stakeholders and the Scrum Team work together to understand Sprint outcomes. As a result, the attendees agree on the next steps for optimizing value. This is based on any changes to the Product Backlog during the Sprint. This is why Sprint Reviews are conducted to gather feedback and progress.
Two-week sprints are reviewed in two hours, and one-month sprints are reviewed in four hours.
Scrum Masters ensure the following: Meetings happen. The purpose is understood. In this meeting, the agenda was covered, and the meeting was conducted on time.
Sprint Review includes: One: A Product Owner invites the Scrum Team and key stakeholders to the meeting. Two: Product Owners explain what items have been completed and what still needs to be completed during sprints. Three: During the Sprint, the Team discusses what went well, what went wrong, and how it handled the issues. Four: As part of the incremental process, the Team demonstrates its work and answers questions. Five: Group members discuss the next steps. In this way, Sprint Reviews provide valuable input to Sprint Planning. Six: For the next anticipated release of the product increment, the Scrum Team examines the timeline, budget, and potential capabilities. Seven: Product Backlog items for the next Sprint are defined in the Sprint Review and the revised Product Backlog.
Event Number 5: Retrospectives. The “inspect and adapt” philosophy guides agile development. As the product evolves, we adapt our plans. Managing our tasks daily maximizes progress. To follow this philosophy, we must work together and apply Scrum. A sprint retrospective meeting serves this purpose. Sprint retrospectives are the most significant yet often neglected practices. Continuous improvement is the goal of the meeting. In the retrospective, beneficial practices are identified, detrimental practices are stopped, and new ones are identified for the next Sprint. Development practices are improved in retrospectives. Making significant changes is unnecessary; a 1% improvement in team effectiveness every Sprint compounded over time adds up to a lot. Immediately following the sprint review is the retrospective. The whole Scrum team attends. A Scrum Master facilitates the meeting, which is time-boxed.
Before starting the meeting, the team chooses a time limit. The meeting length will vary from thirty minutes to three hours. Meeting attendees answered the following questions: One: In response to “What things should we stop doing?” the team looks at detrimental practices identified during the last Sprint. Two: “What should we start doing?” The team identifies practices that improve teamwork. “What is working well that we should continue to do?” The team identifies beneficial practices that should be continued. Recent retrospectives typically introduce these changes. Whether to invite outsiders is up to the team. When teams interact with external individuals during sprints, retrospectives are valuable. The retrospective should be discussion-driven.
The Scrum Master must facilitate these discussions to keep the meeting on track. During a retrospective meeting, action items indicate changes in how the Scrum team works together. Action items are created based on the answers. These action items may only sometimes be assigned to individuals during the meeting. Retrospectives help the team become more effective over time. Ignoring this critical practice prevents agile adoption benefits from being realized.
