How to Run a Productive Weekly Sprint Meeting (Free Templates)

Knowtworthy Staff -

This week we're looking at the weekly sprint meeting: a quick look back at the week that just ended, a decision about what the coming week is for, and the work handed out so everyone leaves knowing what they must accomplish. Teams running one-week sprints will often fold the review, the retrospective and sprint planning into this single meeting, which makes this meeting a cornerstone of the agile process, but also what allows it to get much longer than anyone would realistically like it to be.

You've likely sat through a version of this meeting that’s taken a wrong turn: the retro turns into a debate about one ticket, the backlog review becomes a grooming session with the whole team watching, and the meeting ends with a list of tasks but no single guiding sentence about what the goal of the next week is.

In this article, we'll walk through what a weekly sprint meeting is, what it's meant to produce, when and how long to run it, and who does what. Then we'll go through a free weekly sprint meeting template we’ve set up item by item.

TL;DR: A weekly sprint meeting is a 60 to 90 minute meeting at the start of a one-week sprint where the team reviews the sprint that just closed, agrees a single sprint goal for the week, checks the backlog against that goal and the team's real capacity, and assigns the work. It should end with two things written down: the goal, and who is doing what. A free weekly sprint meeting template for Knowtworthy, Word, Excel and Google Docs is further down.

What is a Weekly Sprint Meeting?

A weekly sprint meeting is the planning meeting that starts a one-week sprint. A sprint, in Agile and Scrum terms, is a fixed-length cycle of work. The 2020 Scrum Guide states that sprints are "fixed length events of one month or less to create consistency," and leaves the exact length to the team as long as it stays the same from sprint to sprint. Two weeks is the most common choice; one week suits small teams, early products and anyone whose priorities shift often enough that a two-week plan is fiction by day six.

Scrum describes several separate events around a sprint: a sprint review at the end (what did we build, and what did we learn from showing it), a sprint retrospective (how did we work, and what will we change), and sprint planning at the start (what will we do next, and how). With a two-week sprint these are often three meetings. With a one-week sprint, three separate meetings would eat a noticeable slice of the week, so most teams run them as one session either at the very start or very end of the week. That combined session is what people often mean by a weekly sprint meeting, and you may have heard of it by other names such as: sprint planning meeting, sprint kickoff, or just the Monday scrum meeting.

Importantly, this weekly sprint meeting sits in between the day-to-day task review of a standup and the larger quarterly reviews in terms of planning and detail.

The template below follows that combined shape: the past sprint first, then the backlog, the goals for the coming sprint, and the assignment of refined tasks. If your team already holds a separate retrospective meeting, the first agenda item gets shorter and the rest stays the same.

What is the main goal of a Weekly Sprint Meeting?

The meeting exists to produce two things: a sprint goal and a sprint backlog. Everything else in the agenda is in service of those two outputs.

The sprint goal is one sentence about what the sprint cycle is for. The Scrum Guide calls it "the single objective for the Sprint" and notes that while it's a commitment, "it provides flexibility in terms of the exact work needed to achieve it." That flexibility is crucial, so a goal like "customers can reset their own password without emailing support" tells the team what to do when a task turns out to be bigger than expected: drop or shrink whatever contributes least to the goal, rather than working late to finish a list. A list of eleven various tickets gives you no such guidance. This sprint goal also gives the team some semblance of momentum, where if you scope the goal of each sprint well, it’s easy to look back and see how much progress you’ve made in such a short time. Real project work is often not so simple, but a nice clear sprint goal is great to have if possible.

The sprint backlog is the set of backlog items the team has picked for the week, each with an explicit owner, plus enough of a plan to start in earnest. The review half of the meeting adds a third, smaller output: one improvement to try this week. The goal of reviewing the last sprint is to find areas of improvement to both continue outputting high-quality work and increase the team’s productivity over time.

If you skip the goal and go straight to picking tickets, you get the pitfall the Agile Alliance warns about: a team "performing a sprint's worth of work but not feeling as though they've made a lot of progress." And if you skip the backlog, you risk not having concrete enough work items to actually achieve that goal.

When should you schedule a Weekly Sprint Meeting?

As we’ve discussed above, you have some options available for when to schedule this meeting, but we’ll go through the most common ones below.

On the first working morning of the sprint, at the same time every week. For most teams that's Monday morning. Holding it first thing gives you the opportunity to set up the plan for the week before anyone gets to work on something else. This approach also has the added benefit of everyone showing up on Monday ready to get aligned for the week ahead. Furthermore, if you’re holding this meeting first thing, you don’t need to also run a standup that morning, saving a few more minutes on an extraneous meeting.

Some teams close the previous sprint on Friday afternoon (a short demo and retrospective) and then plan either Friday afternoon or Monday morning; others do the whole thing on Monday. Either is fine, as long as the review happens while the week is still fresh and the plan is agreed before the work starts.

Two things belong outside this meeting but can easily be folded in by accident. The first is backlog refinement: the work of breaking large items into small, well-understood ones. The Scrum Guide describes refinement as "an ongoing activity," and if it hasn't happened before the sprint meeting, the meeting has to also complete the refinement, with the whole team paying for a conversation that needed two or three people. We have a detailed article about refinement meetings that you can take a look at as well. The second is the daily standup, which checks progress against the sprint goal each morning. You should try to avoid discussing where exactly things are on certain tasks in this meeting, as ideally that will have been prepared ahead of time.

How long should a Weekly Sprint Meeting be?

Plan for 60 minutes, allow up to 90, and try to stay below two hours. Atlassian's sprint planning guide recommends that sprint planning shouldn’t take more than two hours for each week of sprint. Don’t worry if this varies a bit sprint-to-sprint and try to keep things time-boxed ahead of the meeting, but an hour to an hour and a half is realistic for a team of five to eight with a refined backlog.

If the meeting regularly runs past that, the cause is usually upstream and you should try to identify it ASAP. Other Agile specialists point out that when planning regularly feels too long, the real issue may be weak refinement, oversized backlog items or unclear acceptance criteria. Think back to your last sprint meeting that ran long. Was the extra time spent deciding what to do, or working out what a ticket even meant? If it was the second, the fix is simple: make sure your refinement sessions are done before sprint planning.

A rough split for a 60-minute version of the template is 15 minutes on the past sprint, 15 on the backlog, 10 on the sprint goal and 20 on assigning the work; we've put those times against each agenda item in the walkthrough below.

Time-boxing (or setting a fixed limit for each item and stopping when it's reached) matters here because every one of these items can expand to fill whatever time it's given. Putting these times explicitly in the agenda and having someone enforce them is a great meeting practice that you should apply here as well.

How is a Weekly Sprint Meeting Run?

Whoever owns the product priorities brings the ordered backlog; the team decides what fits within the upcoming sprint; one person keeps the meeting on track. In Scrum terms those are the product owner, the developers and the scrum master. Your specific team might not have those titles, and that’s fine; what matters is that the three jobs are handled by someone present.

The person who owns priorities (a product owner, a founder, a team lead) should arrive with the backlog already in order and be ready to explain it. Their job is to make the value clear and to propose a sprint goal. The people doing the work make the final call on how much will realistically fit, because those doing the assigned work will have the best understanding of how long everything will take.

That distinction matters when you're sizing the week. Some common advice is to plan from capacity rather than velocity: velocity is the average amount a team has completed in past sprints, and it's a useful reference, but this week's capacity is what's left after everything else is held out: holidays, absences, support duty, interviews, and whatever else is already on the calendar. Put simply, a team that averages eight items a week and has two people out for two days each should not plan eight items. This is just going to lead to unmet expectations or unnecessary stress.

The Scrum Guide frames sprint planning around three questions, and they map onto our template's agenda: Why is this sprint valuable? (the sprint goal), What can be done this sprint? (the backlog review against capacity), and How will the chosen work get done? (assigning refined tasks). Once the meeting has answered all three, it's done, whether or not the time-box is used up.

One habit is worth adopting from the first meeting (or introducing moving forward): write the goal and the assignments down where everyone can see them, and read them back before you close.

Additional Resources about Weekly Sprint Meetings

A Simple Template for Weekly Sprint Meetings

You should always adapt any meeting template to your particular needs, but below we have some free templates for you to get started with. Every team is different, which is what makes running great meetings a challenge, but meeting best practices often stay the same for different meeting types.

We'll go over every section in the templates attached in this article, so feel free to follow along with whichever version below suits you.

The Knowtworthy version opens as a free live meeting document with no account needed, which suits a weekly meeting well: you can use the same link every Monday, view last week's goal and assignments one document back, and the action items remain visible to everyone during the week. The Excel version is handy if you'd rather track the task assignments in a grid, and the Word and Google Docs versions suit teams who want a simple page to fill in and share.

If these templates don't suit your needs, you can check out our dedicated templates page where you can access all of our free templates and find one that works better for you!

Meeting Information

At the top of the template you should list a few important pieces of information about the current meeting so that anyone could get a good sense of what the meeting is for just at a glance. For a sprint meeting, put the sprint number or the week's dates in the title ("Sprint 14 planning, 5 to 9 October") rather than just “Sprint Planning”, so that searching is easy later on. We also recommend listing who attended. If someone who owns a task wasn't in the room, that's worth knowing during future check-ins.

Meeting Purpose

A meeting's purpose can stay consistent across several meetings, but bits of it can be updated to be relevant to a particular week. For example, in this template's purpose we have:

Discuss and learn from the past sprint. Get aligned on goals for the next sprint along with the task distribution for everyone.

However, depending on the current week's goals, you might update this to something like:

Close out sprint 13 (the checkout redesign) and plan sprint 14: ship the self-serve password reset, and decide whether the reporting work starts this week or next.

The updated version names the goal and the one open question, allowing anyone reading the document later to instantly tell what the week was for without reading the notes.

Meeting Agenda

The actual meeting itself should have a few key phases which we list in the agenda. You can add notes about each agenda item and modify how much time you think each will take as needed, but we've provided a rough baseline for you to work with.

1. Discuss past sprint (15 minutes)

The template breaks this into three questions.

What went well? Start here, and be specific. For example, "The release went smoothly because we froze the branch on Wednesday" is a practice worth logging and repeating in the future; "good week" is not a finding worth noting down.

What needs to be improved? One or two things, and for each one, a change to try this week. If the same item comes up three weeks running, you can note that this should be taken offline and brought up at a dedicated meeting later on.

Was anything not completed or does it need to be pushed to this sprint? This question is crucial to keep teams from stacking up tech debt, but can also be a progress trap. Unfinished work either moves into this sprint (and takes capacity from it), goes back to the backlog, or is dropped. If you aren’t careful, certain tasks can slide into taking weeks longer than expected, with no process in place to prevent this from happening to future tasks. So be deliberate about every task here, and where necessary, make sure concrete timelines are assigned to remaining tasks. If tasks slipping becomes a common occurrence, it may be worth revisiting the length of your sprints, depending on the project you are working on.

2. Review backlog (15 minutes)

The person who owns priorities walks the top of the backlog, in order, and explains what each item is for. The team checks two things: is the order still right given what we learned last week, and is each item refined enough to start? Anything that isn't refined gets flagged for a refinement session and stays out of the sprint. Resist the urge to refine it now with everyone watching (even though it may seem quick and easy to do!). This is also where you count capacity: who's out this week, what's already committed (support, a release, interviews), and how much of the week is left once those are taken out.

3. Discuss main sprint goals (10 minutes)

Agree on the guiding sentence for the sprint. If the backlog review has gone well, the goal is usually obvious; if the team can't state one, the backlog's top items don't add up to anything, and we’d recommend having each sprint be more focused moving forward. Put simply, being able to write out a sprint goal is a good litmus test for a well-formed sprint. Write the goal at the top of the document. It's the line everyone should be able to repeat when the standup asks how the week is going.

4. Assign refined tasks (20 minutes)

Now match the work to the people. Each task that goes into the sprint gets an owner and, where it helps, a rough day for when it should be complete. A task without an owner doesn't get done; a task with two owners often doesn't either (unless you are careful to set a ‘primary’ owner). Our post on what goes into a great meeting action item has the short version: who, what, when.

Before you close, read the list back and check it against capacity one more time. Then read the sprint goal aloud once more and end the meeting.

Adding structure for larger or newer teams

If the four agenda items feel thin for your team, the Detailed Weekly Sprint Meeting Template expands each one: it adds "what tasks were completed?" to the review, breaks the backlog step into goals, bandwidth and unrefined work, and closes with a read-back of the week's goals. It suits a team that's new to sprints and wants the prompts written down, and it's more conducive to detailed notes.

Other templates you might find useful

A sprint meeting sits alongside three other meetings, and each has its own template:

After the Meeting

The final thing to do once the meeting ends is store your notes somewhere safe and share them with your team, so that everyone can look back on what happened instead of asking around about outcomes. For a sprint meeting the notes are pretty much the plan for the week: the goal, the assignments and the carry-overs, which is what the standup will check against each morning. We have a separate post on the best practices for handling your meeting notes afterwards, which you can read here: So you took notes during your meeting, now what?

You can use these notes to bring up to speed people who couldn't make the meeting, or new team members who want a quick picture of what the team is working on this week.

Depending on how you write your notes, you may need to share them over email, or by using a cloud-based meeting platform like Knowtworthy you can share links to your notes directly instead of keeping people up to date manually.

In summary, in this post we covered the basics of weekly sprint meetings and went through a simple template to get you started. As we mentioned above, there's no one-size-fits-all meeting template, and different types of meetings need different kinds of templates.

So if you're interested in other free meeting templates, check out the list of articles we've written on the subject here: meeting template articles. We also host a blog all about meeting and project management best practices, which you can find and sign up to for updates here: the Knowtworthy blog.

We'll be back with more articles like this one soon, so if you found this one helpful, please feel free to subscribe or share the post.