0

We are setting up new Sprint process whereby each Sprint starts on a Monday and ends on a Friday the week after. For example, the start date for Sprint 1 is January 1, 2022 and the end date is January 14, 2022.

Calendar showing initial 2-week Sprint

Should Sprint 2 start on January 15th and end on January 24th, or should it start on January 17th and end on the 28th? If it's the latter, the weekend of January 15th and 16th would be intentionally excluded from the Sprint.

What's the best practice around this?

2
  • Does this answer your question? pm.stackexchange.com/questions/29843/…
    – Bogdan
    Feb 10 at 19:02
  • I'd steer clear of starting new sprints at the beginning of a Monday if you don't have to. It can be quite hard to get going after a weekend, and it's easier to start something new if you already have momentum. For that reason, my team's sprints end and start in the middle of a weekday. Feb 12 at 15:32

5 Answers 5

7

If your Sprints start on Mondays, how can you have a Sprint start on January 15, 2022? That day is a Saturday. Similarly, if your Sprints end on Fridays, how can you have a Sprint end on January 24, 2022, since that day is a Monday?

It seems like you are overthinking this.

Consider how people normally allocate their time, especially your key stakeholders who you would want to be involved in the Sprint Review. It would probably be easier to tell them that the Sprint Review is every other Friday, starting at a specified time. Your Sprint Retrospective can follow that, and your Sprint Planning would be during the next working hours available.

There is no need to count weekends as part of your Sprint. No one should be working, considering the Agile principle of working at a sustainable pace. If weekends are not normal working days, just ignore them.

1
  • 1
    You got my upvote on "It seems like you are overthinking this."
    – Tiago Cardoso
    Feb 11 at 11:07
2

Focus on a Consistent, Predictable, and Sustainable Cadence

Scrum is not very prescriptive about when to schedule the start or end of each Sprint, but the common practice is to only schedule framework events and planned work during standard working days. If the team doesn't usually work on the weekends, then don't base the project plan on doing work or holding events like Sprint Planning on the weekends outside of truly exceptional circumstances.

More importantly, a core tenet of agile frameworks like Scrum is to maintain a predictable cadence for events, meetings, and deliverables. So, if your first Sprint starts on Monday, then every Sprint should generally start on a Monday. Likewise, if your first Sprint ends on a Friday, then every Sprint should end on a Friday.

Of course, holidays, staffing shortages due to the pandemic, or other force majeure events can force the team to adapt the schedule when necessary, but consistency and predictability for both the team and the stakeholders remains the key objective. Starting or ending your Sprints on a different day of the week each Sprint would not meet that goal.

The related question of whether weekends within each Sprint's time box are included in the Sprint or not is a separate topic. That has to be answered by the team based on how they work together and as individuals, how they manage their hours, how they organize their work, how self-managing they are, whether your team has routine coverage on the weekends, and a lot of other considerations not included in your original post. If a high-performing team wants to work four-day work weeks, or spread out the work to include weekends, that's really up to them so long as the framework events are held at predictable days and times, and as long as the process is working for both the team and the stakeholders.

Some of the best engineers I know do their best work at 2:00 AM. From a framework point of view, as long as they're available for the Daily Scrum, Sprint Planning, and so forth it's none of my business how the team self-organizes so long as it's consistent and sustainable for the duration of the project.

0

My answer for this question is the tool that you use for managing your project accept the weekends so yes, you must consider the weekends, if not the 2 weeks sprint will be fit monday to friday. I use Jira and my setup is for use weekends, even we don't work, so 2 weeks for us are 10 days. In Scrum planning we know that and it's the most important thing on or planning!

-1

Most of the agile management tool will assign the very next day your current sprint ends as the sprint start date. So in your case your sprint 2 will begin on Jan 15th and will end on Jan 28.

2
  • 3
    Those are some pretty inflexible tools. Why would you use a tool that drove a cadence or schedule nobody would follow? Always use tools that support your process; never let tools define your process for you.
    – Todd A. Jacobs
    Feb 16 at 0:35
  • 1
    The agile manifesto teaches us "Individuals and interactions over processes and tools" - don't let the tool choice drive your decisions. Feb 22 at 3:22
-4

I work remote & async. People in my team can work anytime, anywhere. That's why I start the sprints on Thursdays and finish them on Wednesdays so that people can also work on weekends if they want.

3
  • 2
    Thank you for your story. Unfortunately it doesn't provide an answer to the question - perhaps it was meant to be a comment? Feb 12 at 15:34
  • No, it was not meant to be a comment. Thank you for your contribution @TobySpeight. Feb 14 at 2:22
  • 3
    How does this answer the question? Although it describes what you do, a good answer should elaborate on why it's the right thing for the asker to do. For example, why do you like to give people the ability to work over the weekends? What benefits have you seen from this? What about problems - how did you mitigate or resolve issues? Since the question is tagged scrum and agile, is this consistent with the values and principles of Agile Software Development and Scrum?
    – Thomas Owens
    Feb 14 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.