What Are Sprints in Scrum & How Do They Work?

This article is an excerpt from the Shortform book guide to "Scrum" by Jeff Sutherland. Shortform has the world's best summaries and analyses of books you should be reading.

Like this article? Sign up for a free trial here .

What are Sprints in Scrum? What are the four phases in a Sprint cycle?

A Sprint is the core process within Scrum. Sprints are fixed lengths of time, usually one or two weeks, in which the team works on a particular task or tasks. The key values of the Scrum framework are developed and maintained inside Sprints. Sprints are where the work gets done, where value is created, and where people turn ideas into reality.

Here are the four phases of a Sprint cycle.

Phase 1: Plan

What are Sprints in Scrum? Sprints are where all the work gets done, and there are four phases. The first Sprint phase is to plan. At this stage you should have a prioritized task list and a Scrum team ready to begin working. The goal of this phase is to determine three things:

How the Sprint will bring value. The product manager begins by proposing how the product will increase in value during the upcoming Sprint.
Which tasks will be completed in the Sprint. The team then chooses which items from the task list they will complete. The tasks must be fully completed within the chosen time frame, meeting the standards for completion defined in the task list.
How the tasks will be completed by the Developers. The last step of Sprint planning is to plan out the work needed to complete the chosen tasks. This can be done by organizing the workload into daily tasks, but those decisions are left to the Developers. The Product Manager and Scrum Coach should have no say in how the tasks are completed.

Planning as a Habit

In The 7 Habits of Highly Effective People, Stephen R. Covey gives advice on how to best prioritize your time and achieve your goals. When trying to tackle personal goals, he suggests weekly planning. Weekly planning is broad enough to allow for adjustment but narrow enough to ensure things are getting done. Covey gives a step-by-step guide to weekly planning:

1. Identify your roles
2. Identify one or two goals for each role
3. Assign a day for each goal
4. Schedule time for enriching activities
5. Build in time for the unexpected
6. Adapt the plan as needed

Covey’s advice thus aligns with Sutherlands: Covey recommends weekly planning because it can allow for frequent adjustment, and Sutherland recommends planning each Sprint for the same reason, to allow for frequent adjustment as the project proceeds.

Phase 2: Meet Daily

Sutherland recommends that during each Sprint, the Scrum Coach and Developers hold short meetings every day. He states these meetings should be held in the same place, at the same time, and they should be no longer than fifteen minutes. Consistency and simplicity are important.

During the meeting, each team member should report:

What they accomplished yesterday
What they will accomplish today
What’s slowing them down

This helps the team know exactly where they are in the Sprint, what needs to be done next, and where they can improve. In these daily meetings, there should be no additional tasks assigned by management. If there are any impediments to the team’s progress, it’s the responsibility of the Scrum Coach to remove them. The Daily Meetings help build communication, clarify direction, and increase efficiency.

Use Multiple Lists to Increase Efficiency

The Scrum framework gives a team a structure to the workflow: Each week or two weeks, a Sprint is completed and each day, the team meets to discuss progress. Different task lists are used for each type of check-in. Sutherland isn’t the only management expert who recommends using different task lists for different purposes: In Eat That Frog, Brian Tracy recommends four different lists to use depending on which timeframe you need to plan for:

Master list: This contains everything you want to do. Any time a new idea or task comes up it’s added to the master list.
Monthly list: At the end of each month, move items from your master list to your monthly list.
Weekly list: Build the weekly list as you work. This way, at the end of each week you will already have your next week roughly planned out.
Daily list: Take items from the weekly list and list the tasks you wish to complete that day. Check off items as they are completed.

Phase 3: Demonstrate

After each Sprint, the team must demonstrate what they’ve produced in the Sprint. Anyone with a stake in the project or its outcome is invited to see this demonstration. Outside participants, such as customers, are encouraged to attend and give feedback. If no stakeholders or customers are able to attend, the Product Manager acts as their stand-in and attempts to view the demonstration from an outside perspective.

The idea behind the Sprint demonstration is to force Developers into making a finished, demonstrable product during each Sprint. Sutherland recommends building a prototype—something you can show the customer that actually functions even if it’s not fully fleshed out, so that you don’t waste time trying to make a perfect product but instead focus on building something that works that you can improve later.

Prototyping

In Inspired, Marty Cagan discusses the usefulness of prototypes in software development. Prototypes take less time and energy to make than a finished product, and they allow the team to flesh out ideas and see what works. Cagan gives four types of prototypes:

Feasibility Prototype: A prototype used to determine if a product can actually be created. You should only build enough to ensure the team is capable of completing it.
User Prototype: A user prototype is a non-functional simulation of the final product. A simpler user prototype may be a bare-bones version to help the team visualize the product. A more complex user prototype may be tested internally and externally to see how it works.
Live-Data Prototype: A pared-down but functional version of the final product. A live-data prototype is used to test if a product is commercially viable by getting real data from test users.
Hybrid Prototype: This is a combination of the previous three types. These are the least scalable of the four types, as they are meant to be built quickly and provide feedback.

Phase 4: Reflect

After demonstrating the product, the team then examines the previous Sprint. The aim of the Reflection is to find ways to increase productivity and efficiency within the Sprint process. Team members should look at what went right, what went wrong, and how the team reacted to any obstacles or problems that arose. They should identify potential changes that could be made to improve the process. Then, they should decide which changes will have the biggest impact and look to implement them in the next Sprint. With each Sprint reflection, the team should be finding new ways to increase productivity.

This part of the process requires a high degree of maturity and trust, as each team member must take responsibility for their actions and look for ways to improve.

Accountability

The reflecting phase is about encouraging accountability: Whether working individually or with a team, you must hold yourself and others accountable if you wish to be successful. The Oz Principle details how to lose the victim mentality and assume responsibility for your actions. The authors lay out four steps to help practice accountability:
1. Face the facts: You must face reality if you wish to be accountable. This includes recognizing when things around you change, making space for other people’s perceptions, and being honest about your own shortcomings.
2. Admit your role: Acknowledge that you aren’t just a victim of circumstance and that your actions contributed to those circumstances. Once you recognize your own culpability, you can more easily find a solution.
3. Take responsibility for solving problems: If you see a problem, help fix it. It can be easy to say “not my job” or “not my fault,” but being accountable means helping to solve the problems you see around you.
4. Take action: Once you recognize a problem, you must stay committed to finding a solution. Don’t let any obstacles get in the way of your goal.

On top of individual accountability, The Oz Principle also examines how to be accountable as a team. A team’s accountability can have a direct effect on their creativity, camaraderie, and overall performance. Here are some ways you can nurture organizational accountability:
– Recognize you and your team members are interdependent
– Focus on results instead of individual responsibilities
– Use rewards as a motivational tool
– Encourage two-way feedback
– Find the underlying causes of a problem

What Are Sprints in Scrum & How Do They Work?