You’ve recently heard you are joining a scrum team and learned that there are “rituals” that take place. Even more important, you’ve heard that you are working in a “sprint cycle.” So, what is a sprint cycle?
A sprint cycle is a unit of work taken on by scrum teams. The length of that unit of work is consistent.
For most teams, a sprint is either one or two weeks. Within that time period, you have rituals — sprint planning, sprint execution, sprint review, and a sprint retrospective — that are how the team stays aligned on important work.
In this article, we will talk about what scrum is and then talk about each section of a sprint cycle.
What Is a Sprint Cycle?
A sprint cycle is a unit of work taken on by scrum teams. The length of that unit of work is consistent.
What Is Scrum?
Scrum is the methodology behind a sprint cycle and lays the foundation of a sprint cycle. I define scrum as follows.
“Scrum, a popular product management framework, helps development teams deliver incremental value. In other words, Scrum helps product teams take large projects and break them up into small chunks to monitor progress and practice continuous delivery.”
The whole process is divided into smaller units called sprints. A sprint is the standard timespan that teams have to deliver value, and it is often one or two weeks. This helps create a consistent workflow for other teams, with regular check-ins that are driven by sprint planning, sprint execution, sprint review, and sprint retrospectives.
Let’s make this real by joining Jim, the scrum master for a product team at BobCo, a fintech company that focuses on helping accounting teams by providing software solutions. We will watch the team go through each part of the sprint process and see how it helps them focus on building the right products for customers. First, let’s talk about the sprint planning process and join Jim as he helps the team figure out what’s next.
4 Steps of a Scrum Sprint Cycle
- Sprint planning.
- Sprint execution.
- Sprint review.
- Sprint retrospective.
1. Sprint Planning
Sprint planning is a ritual in which the product development team determines what they’re going to tackle in the upcoming sprint. It happens before the sprint begins. A good sprint planning meeting has three important components.
3 Components of Sprint Planning
- A clear set of goals for the sprint. This is the outcome the team is looking to achieve, driven by the outputs that are defined by some ticketing system, often Jira. Clear goals mean that the product team understands how to drive valuable outcomes from outputs that are viable, usable, and feasible within the sprint.
- A clear understanding of what won’t work for the sprint. This is where a team removes anything that isn’t helpful for the goal and sets it aside in the backlog. This step helps the team stay focused on what they intend to deliver.
- Clear communication. What is viable, feasible, and usable is defined in conversation by the product development team, which includes a product manager, product designer, and product engineer(s). The scrum master facilitates this conversation, and most concerns should be addressed before work begins.
At BobCo, Jim sets up for the sprint planning meeting by putting all the backlog items into three buckets that represent the possible outcomes before the meeting. This is important because once the outcome is set, he can put the other backlog items away and focus the conversation.
He starts the meeting by asking the team which outcome seems most valuable based on the work that is currently happening in the sprint. The team decides to focus on accessibility since the work required will make other tasks down the road easier for the team thanks to the accessibility of the new features.
The team immediately puts everything outside of accessibility into the backlog. The meeting then focuses on how to set a clear outcome for the sprint by laying out the possible tasks and asking the team what they think they can accomplish during the sprint.
He does this by using a point system that he has worked out with the product manager to estimate the value of each task. They have 100 points, 50 of which Jim takes away immediately to make space for any unforeseen consequences. For example, a color contrast ticket is worth 20 points, a text sizing one is worth 20, and a mobile accessibility ticket is worth 10 points. Those three add up to 50 points.
Jim looks at each ticket to ensure that the requirements are clear to the team. He also asks if they’re viable to the business, usable by the customer, and then feasible by the team. Any extra requirements add more points to the estimate. Some background work on the infrastructure to make the work feasible had slipped their minds, so the team adjusted the tickets. The team adds 25 points worth of additional work.
By the end of the meeting, they had landed on 75 points since they have a clear objective: improve accessibility. Jim can now prepare for the next part, sprint execution.
2. Sprint Execution
The team completes the work during the sprint execution. This step makes up the bulk of the sprint.
The teams self-organize cross-functionally to get things done, and the scrum master’s job is to help the team get to the goal set during sprint planning. One of the ways the scrum master helps is by running the daily scrum, sometimes known as the standup, to help teams articulate the work they’re doing and raise concerns about any blockers.
These are the questions that the International Scrum Assembly suggests for a standup:
3 Questions for a Scrum Standup
- What did I accomplish since the last daily scrum?
- What do I plan to do by the next daily scrum?
- What are the obstacles that can potentially prevent me from making progress?
Jim asks the team these questions every morning at 9 a.m. As he hears about blockers, he works to fix them by understanding the problem and working with those affected to solve it. For example, a blocker may be getting insights from the compliance team on accessibility standards. In this case, Jim would work with the compliance team to get the necessary information so the work can proceed.
3. Sprint Review
In a sprint review, the team shows what it accomplished while stakeholders provide feedback. The team presents the outcome of the sprint to the attendees, showing each output to solicit feedback. The sprint team is able to communicate what they’re working on, why the sprint is important to the overall company mission, and, in some cases, even put the features in the hands of attendees to help them understand the product better.
Sprint review is a critical part of the process because it allows the team to get direct feedback from the rest of the company and fill in any knowledge gaps that may have arisen during the building process. A sprint review is more workshop than presentation, as the team can work on any feedback it receives right then and there.
Jim sets up the sprint review by calling in a representative from sales, customer success, and the infrastructure team, as their feedback is critical. He tells everyone beforehand what the goal of the sprint was — that they were focusing on improving accessibility — and starts the meeting. With each output the team presents — the color contrast, text, and mobile work — he probes the attendees to provide feedback.
The product development team answers questions as they come up with each output. The customer success team noticed a few issues with the mobile application, which is important for a few customers they are looking to retain. They add those concerns to the backlog, where the team can address it in the next sprint planning meeting.
4. Sprint Retrospective
The team needs to understand how well they did, which is where the sprint retrospective comes in.
The sprint retrospective is the final part of the process, where the team gets together and asks a few questions:
Sprint Retrospective Questions
- What went well? What did the team do well that helped it achieve its goals?
- What didn’t go well? Were there any blockers that stopped the team from an optimal work environment?
- What could we improve? What is at least one thing we can do to make our working relationship better?
The idea of a retrospective is to use the sprint to find places where the team is suffering operationally and improve with the next sprint.
Jim sets up the retrospective by putting up the last sprint outcome about accessibility for the team and leads off with a simple question: Did we accomplish this outcome?
That question helps the team orient themselves against the planning session. Did they overcommit? Even if they accomplished the outcome they wanted, were they blindsided by matinence? Were they able to do a healthy amount of research to set up the next sprint? Did they communicate the outcome well enough to have buy-in from the rest of the company?
The team accomplished the outcome, but realized during the sprint review that the customer success team was lost and they missed those retention requirements, and so they resolved to set aside more time for enablement.
Jim then asked those three questions (what went well, what didn’t go well, and what could they improve) and made sure to collect that to go over during the next sprint planning meeting.
Scrum Sprint Cycles Drive Smart Development
This process helps teams by allowing time for teams to react with shorter cycles. A great scrum process means comfort with change. By checking in a bit more often, teams discover problems sooner and are able to be more efficient by adjusting in the span of weeks instead of quarters.
