Chapter 4: How to Manage Sprints and Sprint Events, and the Backlog  

There are three key elements to managing an Agile Team when you get past the people element. You need to be able to manage sprints, Scrum events, and backlog. It is likely that other people may take the reins on managing certain pieces of a sprint, Scrum event, and the Product Owner may even delegate control of the backlog. But it is important that every person on the team understand the core purpose of these three facets of an Agile Project. 

One of the common complaints about Agile, or the argument against using Agile, is that there are too many meetings. Because of the emphasis that Agile places on communication, these meetings are necessary. Scrum events and sprints demand a high level of communication, so there won’t be meetings where everyone sits around, not addressing the primary issue. Agile meetings are often restricted on time, highly structured, and exist with a clear purpose.  

The Daily Meeting 

The daily meeting, the daily Scrum, the Kanban meeting, the daily standup, and many other names all reference the same meeting. Many Agile teams will avoid using the terms Scrum and Kanban because they refer to specific Agile Methodologies. But Scrum and Kanban are also common jargon among Agile Teams, so it’s not uncommon to hear them used in reference to this daily meeting. The daily standup term came from Agile Members standing up during the meeting to keep the meeting as short as possible. 

The daily meeting exists to report the status of different tasks and the backlog to the Product Owner. The Scrum Master takes the wheel on the daily meeting by discussing what each person in the team has accomplished, where the project is at currently, and the progress of the current sprint. This is not the meeting to talk about conflicts unless a prior conflict has arisen and is impacting the team’s progress. This particular meeting is the forum for each team member holding the other accountable and for the Product Owner to ask questions. The Scrum Master should serve as the communication conduit during this meeting. They should interpret any answers that the Product Owner didn’t fully understand, and help the Development Team understand requests or information from the Product Owner. This meeting is the opportunity to plan out the next few hours. 

Tools for the Daily Meeting: 

● Kanban/Scrum Board – This board, although called a Kanban or Scrum board, is often used in Agile Teams even when they’re not using the Kanban or Scrum methodologies. 

● The Parking Lot –All questions or concerns brought up that aren’t pertinent to the work currently being worked on get put in the “parking lot.” It’s the equivalent of “putting a pin” in something. 

● Timer –It is important that the meeting only lasts for 15 minutes. If the meetings go longer than this, they can devour the entire day. 

● Project Calendar –Project calendar outlines the current sprint goals to ensure that daily tasks stay in line with the overarching goals.  

What is a Sprint?  

A sprint is one of the things that will drive an Agile Team forward. Sprints are another term for iteration, which refers to a short stretch of time when the team works on specific goals. The sprints are typically the heart of the Agile Methodologies, and they help people work within an Agile Team with a minimal amount of frustration. The series of iterations help to bring down giant projects into manageable segments. 

Every sprint starts with a sprint planning event. The idea of sprinting is that through careful planning, the team can be in constant motion without being overworked. Sprint planning is done as part of a collaboration between the Product Owner, the Scrum Master, and the Development Team. It involves the entire Agile Team. 

Sprint Planning Event 

There aren’t necessarily hard rules about the sprint planning event, but there are some commonly adopted practices. For example, most Agile teams put a two-hour limit on the sprint planning event. That limit ensures that the meeting only involves sprint planning, and it creates a sense of urgency because two hours might not be enough time to plan out everything. The time limit is a way to keep everyone focused and eliminate unnecessary conversation. Additionally, sprints are usually limited to two-week timeframes. 

So why does it take about two hours to map out the next two weeks of work? Initially, the meeting will be led by the Development Team that will assess all of the work needed to deliver on the sprint goal. Typically sprint goals will cover a singular function or achieve a desired effect within the software. The Development Team will initially take the helm and map out what they can or cannot deliver over the next two weeks to achieve this sprint’s goal. Typically the initial sprint might just be planning out the project itself and defining key features or functions expected of the software and the creation of the backlog. That sprint backlog will continue to receive updates or changes after every sprint planning event. 

Now, each person should thoroughly prepare for a sprint planning event. The Product Owner must ensure that they arrive with an up-to-date backlog, notes from the last sprint review, feedback from the stakeholders, and their vision of the product. The Development Team, if they know of the upcoming sprint, should have not only ideas as to what their task list will look like, but feedback on how the recently finished sprint will impact the next two weeks. Finally, the Scrum Master must come with the updates from the team that the Product Owner needs to hear an in-depth explanation of how those updates will impact this particular sprint planning Event. 

You may have begun to notice that with the sprint system, the only thing the team focuses on is the current step or sprint. It’s true. Many Agile teams work with a very limited scope of focus for their sprints. However, during these sprint planning events, the team has the opportunity to assess the future of the project. During sprint Review Meetings, they have the opportunity to reflect on future progress, challenges, and setbacks. The Product Owner is the one person who must have a clear line of focus and a big-picture view of the project. All others involved will dedicate their focus to the sprint, and that starts with the sprint planning event and ends with the sprint Retrospective event. 

Sprint Review Meetings 

Depending on who you speak with, the Sprint Review Meeting is either the most or least important of the sprint meetings. Unlike the sprint planning event or the sprint retrospective, the sprint review is not a formal event. That doesn’t mean that the sprint review is optional. In fact, it is recommended for every team to use any methodology of Agile that calls for working in iterations, which is nearly all of them. There is a purpose in keeping them informal in that the team shouldn’t “waste” time preparing for a meeting that is really more like a check-up. Some “rules” that exist for sprint review meetings include: 

● No PowerPoints 

● No more than a certain time spent in the meeting, usually one hour. 

● No meeting minutes 

What should happen during a sprint review is : 

● Review the progress in the sprint 

● Discuss the work and demonstrate, if possible 

● Identify pain points 

● Update status of the sprint 

● Collaborate for the remainder of the sprint 

The sprint review is the opportunity for the team to come together and assess where they are in the sprint. They may acknowledge each other’s accomplishments and demo new features. Additionally, it’s one of the times that the team is not so sequestered from everyone else. Participants in these meetings can include the Product Owner, Scrum Master, managers, interested businesspersons, and even developers from other projects. The one thing that should happen during this meeting is that the backlog should receive an update. The Product Owner can do this quietly throughout the meeting and, in the end, review it with the Development Team to ensure that they captured everything. Additionally, the Product Owner’s role in this meeting is to assess the quality of the work and bridge any communication gaps when it comes to how a function or feature developed during that sprint should operate. 

Sprint Retrospectives 

One of the elements that keep Agile Teams together and working collaboratively is the regularly scheduled retrospectives. Sprint retrospectives are the opportunity to focus on continuous improvement, identify the good, and identify the bad. Sprint retrospectives are important, but many in the Agile community feel that these are the most painful areas for the team. Sprinting retrospectives can quickly turn into meetings where one person is getting called out, or people experience a multitude of their ideas being put down. 

At a sprint retrospective, the Scrum Master, Product Owner, and Development Team should all be present. This may also be a time where you see executives or higher-level management checking in on the project. However, a sprint retrospective should never focus on the Product Owner, the Scrum Master, or any visitors coming to the meeting. In fact, these meetings should exist exclusively for the Development Team to express themselves. Typically sprint retrospectives are not the platform to introduce change requests or give negative feedback. 

The ideal result of a sprint retrospective is that the team will walk away with greater confidence in their self-organized work structure, enable better collaboration, and result in happier developers. Usually, happy developers mean happy end-users. 

So what needs to happen for a successful sprint retrospective meeting? First, someone must take the reins and set the stage. This usually falls to the Scrum Master; however, the Product Owner may see this as an opportunity to devote more time to the team. Set a time for everyone to arrive and ensure that the environment is ready before the meeting starts. 2nd, gather the data. Every sprint retrospective meeting must have the most completed and up-to-date version of the backlog and any information pertinent to this particular sprint. That means that whoever is leading the sprint retrospective meeting should check in with the individual team members to determine if they have data or information that needs to be shared with the team. 

The remaining three steps for a successful sprint retrospective meeting will come during the meeting itself. Preparation is important, but the meeting has a purpose, and it’s largely to generate insight, make decisions, and close the sprint. 

Generating insight will stem from a series of questions that you’ll need to ask your team. Common questions include: 

● What went well? 

● Was there additional motivation during this sprint? 

● Did any training, skill, or particular knowledge contribute to the sprint? 

● Did anything go wrong? 

● Was there anything that posed a particular or unexpected challenge? 

● How did the team respond to the challenge? 

● If something went wrong, was it because of incorrect implementation, confusion during communication, or an unexpected technology challenge? 

● What were the team’s learning points? 

● Was there information learned during this sprint that could be useful to other teams? 

● What actions were implemented and improved work? 

● Identify one thing you would have changed during this sprint, and how would you have changed it? 

● What strategies worked during this sprint? 

If you notice, the flow of these questions goes from positive, to negative, to analysis, to corrective opportunities. This flow leads the negativity to a very small window to take hold, but it is that window of assessing what went wrong and how the sprint didn’t go as planned that can turn a sprint retrospective from a very productive meeting to a very challenging meeting. 

If a Product Owner or Scrum Master is leading this meeting, it may be important for them to realize that they don’t have hierarchical power over the team. It is not their duty to course-correct the team or to scold them for things that went wrong during the sprint. They may offer insight into corrective action for the upcoming sprint, or even information that may not have been available to the team. But it is very important that these meetings are discussions that largely revolve around the Development Team, what they think, and their lessons learned. 

Do’s and Don’ts of Sprint Events 

As with most things within the Agile Spectrum, there are no clear rules on sprint events. We’ve mentioned a few guidelines above, such as sprint planning events not lasting more than two hours or keeping your sprint reviews informal. There are some general guidelines that can help new leaders or people new to project management. 


● Make meetings “safe zones” rather than witch hunts. 

● Motivate participation by leading with questions 

● Replace “Yes, but…” with “Yes, and…” in every situation 

● Understand that shy or introverted people don’t want to be called out in a meeting but do having meaningful input. Prompt them for response respectfully. 

● Plan your meetings, but remember to remain flexible to change. 

● Use sprint events to boost team morale. Say no to distractions, but say yes to fun and engaging conversation. 


● Allow blame. There is no blame in Agile. 

● Don’t let negative feelings or emotions fester; address them as quickly as possible. 

● Invite people into any sprint event or meeting without discussing it with the team first. No one likes a surprise visit from a high-up manager in a meeting when their work is put on display, or when their progress is under review or receiving critique. 

● Strike action points or improvement opportunities. Even if those recommended improvements may need to be scheduled down the line, action points and improvements are signs that the Agile Team is focused on the value of the product. 

● Don’t spread information about the team or the project without giving the Development Team the lead. 

● Always follow one meeting format. Mix it up, and if you’re out of ideas to rearrange meeting patterns, then ask your fellow teammates.  

What is the Backlog? 

Although this chapter looks extensively at the sprints and sprint events, these wouldn’t be possible without the backlog. The backlog is the comprehensive list of tasks that are necessary to execute the larger strategic plan properly. The larger strategic plan may, or may not, be a formal document, but the backlog is a foundational element of Agile, and it drives every sprint. 

Without the backlog, the team has no idea what’s in store for the next sprint and can’t plan out where to begin on the next feature, bug fix, or infrastructure change. Agile teams certainly don’t have a hierarchical structure, but the product backlog is the only authoritative source that directs the team throughout the entire project. The product backlog shows each item necessary to move forward with the project; however, it does not guarantee that this set of tasks will result in a successful product. 

During sprint planning events, the team will look at the backlog and review each item to determine if it is necessary, valuable and if it is automatable. Additionally, during sprint reviews, the team will use the backlog to determine their progress and identify if there are further along in the sprint than initially planned or if they have fallen behind. During sprint retrospective meetings, the Product Owner will update the backlog, and the team will review the set of items to determine if anything was removed or added for the sake of product value. 

Now, backlogs can vary in size, and different Product Owners will involve different levels of detail in the backlog. The core benefit of having a backlog regardless of how detailed or extensive is that it’s a placeholder for future tasks and future conversations about the ultimate outcome of this project. The importance of the backlog cannot be understated, and it needs to be an integral part of every sprint event, including daily meetings.