Why the last day of a sprint is so important for your team

When using SCRUM or other frameworks with iterations, some of the doubts that hunt our teams regarding the best day to finish a sprint are: are we finishing the iterations/sprint on a proper day?, is there an alternative day more suitable and more efficient? or are we delivering value aligned with the business?

Unlocking tech talent stories

March 22, 2021

When using SCRUM or other frameworks with iterations, some of the doubts that hunt our teams regarding the best day to finish a sprint are: are we finishing the iterations/sprint on a proper day?, is there an alternative day more suitable and more efficient? or are we delivering value aligned with the business?

Of course – and because most agile frameworks are perspective – some are not answered with a recipe. When there are no right or wrong answers, the empiric process advocates the adoption of “inspect and adapt” mantra. And that’s what we did here at Landing.Jobs.

Inspect : Ask the community

The best way to start with the Inspect was to go out and ask the community. As a member of the CTOs.PT, a community of technology leaders in Portugal, Istarted by an informal slack poll to understand the weekday on which other technology leaders were finishing sprints with their teams. The following graphic depicts the result of the survey:

In what day does your team finish sprints?

Although there is no majority around one of the days, there is a solid polarization to the week’s end and start (Friday+Monday). Of course, the poll triggered some comments and discussions with essential insights to understand that decision’s reasoning.

Friday: Sprint Cycle is not the Release Cycle

Some of the teams using Friday as the last day had some particularities behind it.

In some of these cases, teams were finishing the sprint, but the code was not going to production that day because they were using a different release pipeline. So the code would be released some weeks after finishing it.

Other teams that had a fixed time to release to production. They were finishing the sprint, but the code would only go to production on Sunday night so that there was a team to support it on Monday morning.

These teams that are finishing the sprint on Friday have the iteration cycle decoupled from the release cycle. This event is used as a formality to give a sense of completion so that the team members felt they could finish the week and go home with the job done.

End of sprint and Continuous Deployment

Continuous Deployment, the engineering practice that advocates software functionalities delivered to production automatically and frequently, is a solid argument to make you decide which day is the best to finish the iterations.

Before starting these endeavors to look at what would be the best day, at Landing.Jobs we were finishing the sprints on Friday. Because we are practicing Continuous Deployment at his full extent (aka: all features go automatically to production after being reviewed and tested), Friday was becoming a strange day to finish the sprint. Teams were not working during the weekend, so we were just finishing the sprint as a formal act. Developers had the common sense only to deploy that code to production on Monday. So we were just fooling ourselves and becoming inefficient: the new iteration was starting on Monday, but developers were starting the week busy ensuring the deployment to production of features from the previous sprint.

Experiment : Sprint ends on Wednesday

The first step to Adapt is to run experiments, and that’s what we decided to do. There were many bank holidays on Tuesday during December, so we chose to move the end of Sprint to Wednesday. This was the rule during the sprints in December and it was extended to January, even after that period of bank holidays.

The first signs that something was not ok happened during one of the last retrospectives. Some developers started questioning if we were continuing to have the end of the sprint on Wednesday. Going a bit deeper to find out the reasons behind those questions, we discovered some insights:

  • Technically we were better and more aligned. Finishing the sprint in the middle of the week, really means that the code was going to production on the same day. We were not fooling ourselves.
  • It was strange to finish an iteration in the middle of the week because we had a sense of misalignment with the rest of the company areas. The business was running, and we were switching context in the middle of the week.
  • Using Friday as the last day was giving a sense of completeness of work before the change. Developers missed that sense of coming on Monday and feeling fresh to start the week with something new.

Adapt and be flexible

So we were at a crossroad… we didn’t want to go back to a model where it was not coherent and efficient, but we still needed to be aligned with the business and have developers feeling engaged. The discussion brought the light, and we just had to be flexible: Monday! That would be a great day to make the transition from one sprint to another one.

We now have Monday mornings to focus on finishing any items, sending things to production, and give a real sense of completion to the team. Monday afternoon is around the Demo and Retrospective ceremonies for the finishing sprint and Planning the next iteration. Usually, this still gives us time to start developing during the afternoon. Eureka!


Team needs and pains might differ depending on the maturity of the development process and delivery practices. There are no silver bullets when deciding which day is the best for finishing your iterations, but definitely, you can start by inspecting and adapting on:

  • Teams should improve and be empowered to build and deliver customer value as quickly and independently as possible, without requiring hand-off to other teams or deferring their work. So the discussion around what is the best day to finish the sprint usually covers underlying blockers that avoid teams achieving a higher level of autonomy.
  • Ceremonies must mean something and deliver value: don’t maintain those ceremonies just because you always did them a certain way or because it’s in your team’s comfort zone. Discuss the topic openly and transparently with your teams, and don’t be afraid to conduct experiments. You will see that from discussions and experiments, the real problems will arise.
  • Aligning your delivery process with your development process: this is probably one of the most common pitfalls behind the discussion of the “best day to finish the sprint”. Decoupling the sprint cycle from the release cycle gives the team a false sense of completeness or safety. Inspect why this is happening, discuss and start solving it.
  • Align with business: This is a key factor for choosing the best day to finish your sprints. Aligning with business will amplify the impact of the value delivered and give a sense of cooperation and closeness between different areas of the company.
Submit a Comment

Your email address will not be published. Required fields are marked *

Share This