Overview of an Agile Sprint Events Schedule

Confused about the correct sprint ceremony schedule? Does the sprint planning come before or after the daily scrum? For new Agile practitioners, all of these meetings can be confusing and hard to keep track of.

David Hawks walks you through a sample 2-week sprint, with the timing for each ceremony, as well as the participants and time boxes.

Video Transcription (has been slightly edited for brevity and clarity):

Sprint Event Schedule

Hi, my name is David Hawks with Agile Velocity and today I’d like to share with you a typical sprint schedule. So, what we have here is a normal calendar, Monday through Friday. Hopefully, your teams aren’t working on Saturday and Sunday. And what we recommend is that you do 14 calendar day sprints, not 10 business day sprints. While that may seem the same, what we really want to do is focus on having a consistent cadence; so if we plan on a Wednesday, every other Wednesday we would do planning. If we do 10 business days and we have a holiday, so the next time would plan on a Thursday, and then we have a holiday and the next time we plan on a Friday, and it keeps the team from having a rhythm, or cadence. And as humans, we like rhythm, we like cadence.

We also recommend you do not start or end sprints on Mondays or Fridays. The reason for that is if you start and end Mondays or Fridays, you have a lot of the scrum events happening on Monday and Fridays. We have a lot of holidays and vacations and people out on Mondays and Fridays, so we don’t want to have events happening on days where we’re maybe not as focused or people consistently out on our team. What that means is we’d like to start our sprint on Wednesday or Thursday—which is what we’d typically recommend for a 2-week sprint. So, let’s say we start our Sprint on Wednesday morning, with the first scrum event, Sprint Planning. We’d start Wednesday morning with sprint planning for a two-week sprint, time-boxing it up to about a half a day. We would plan that time box and if we finished in 2 hours and 23 minutes, then great. Which means that 2 Wednesdays later, we’d probably have another sprint planning.

Daily Scrum

On Thursday, most teams choose to do their daily scrum in the morning. It doesn’t matter if you do the daily scrum in the morning, in the afternoon, right before lunch, or right after lunch, as long as it’s consistent throughout your sprint and it’s at the same time. We like rhythm, so it’s a dependable rhythm that every day at 9:30 we’re going to do a daily scrum. So if it’s in the morning, that means on that first Wednesday, we probably didn’t have a daily scrum because we didn’t have anything we were already working on, but we would have a daily scrum happening throughout our sprint and it’s time box for no more than 15 minutes. If we’ve done a good job of sprint planning, that means we should be able to finish our daily scrum in no more than 15 minutes.

Review and Retrospective

Now, the other thing is what would we end with? What are the two scrum events we would end our sprint two Tuesdays later? One is the sprint review the other is the sprint retrospective. You can do these in either order, there are pros and cons of doing one before the other. If you do the retro first, you can share in your sprint review with your stakeholders what you learned and what you’re going to do about it. The downside is the review doesn’t go well, you’ve already had your retrospective and you might not be able to take that feedback into your retro. The advantage of doing the review first is that you can retro on how the review went. You can do either way. For the review, just make sure it’s a time your stakeholders can make it.

We would have this kind of cadence throughout the sprint. Which means on the following Wednesday, we would start the day with another sprint planning. There are no gaps between one sprint ending and the next sprint starts, it just flows nicely into the next sprint. Some teams choose to do all the scrum events on the same day. Maybe on Wednesday, they are ending their sprint with their review and retro in the morning and then in the afternoon, they do sprint planning. Some teams like having all of them on the same day, but some teams hate having all day meetings. Do what works for your team.

Backlog Refinement

There’s one more event that I recommend, which is backlog refinement. There is no set timebox in Scrum Guide for backlog refinement, but I usually recommend 1 hour per week of your sprint. I recommend a practice of doing backlog refinement for a couple of hours in the middle of the sprint. I like to do it right after the daily scrum so it’s just 1 timebox asking developers to step away from their desk as opposed to fragmenting their day. It’s about 2 hours and sprint planning is up to 4 hours, daily scrum is 15 minutes. The good thing about doing backlog refinement on Wednesday is that you have a cadence of every Wednesday, we’re doing some type of planning —either sprint planning for the next two weeks or backlog refinement that’s preparing us for the upcoming sprints. Also, if we’re doing backlog refinement in the middle of the sprint, it leaves a couple of days for the product owner to get answers for any questions that come up and gives the teams some time to do any research to prepare for upcoming sprint planning.

The other timeboxes I didn’t mention: retro for a 2-week sprint is about 90 minutes. Again, if you finish in 63 minutes, great, but book 90 minutes so you don’t feel rushed.  For the review, I recommend if you can do 30-60 minutes with your stakeholders, that’s pretty good. The book answer is no more than 2 hours for a 2-week sprint.

That is what a sprint would look like for a 2-week sprint.

More info via Scrum Alliance.