Move the end of sprint to W2, Friday 23:59 UTC

I know you’ll run across my objection to dead days once you read the thread, but here it is again: I don’t think dead days are compatible with asynchronous planning.

1 Like

The stress level rising when we get near the sprint end is a combination of a lot of responsibilities piling up: epic planning, next sprint planning, delivering work for review, participating on estimation session, and going through a massive and stressful checklist.

I’m not a fan of creating multiple deadlines in the sprint, but we could experiment by making a poll to decide the most stressful task of the end of the sprint (from the last 3 days), and with the results in hand, change the deadline of the most voted one to earlier in the sprint (forcing people to do it earlier, avoiding it piling up with other responsibilities).

I’m only suggesting this because our “default” behavior is to delay things until inevitable, so when stress/burnout/health issues/excess of meta-work catches up to us we fallback to that.

Not sure this is the best way though, just something that came to my mind. Maybe its just better to leave the processes as is (I think they are good/well-structured) and address the underlying issue causing planning failures: stress (this discussion is probably better suited for a separate post though).

@demid Thank you for bringing this suggestion up, and to everyone here for discussing it – it’s definitely good to review our processes from time to time, and see if we can do better. :+1:

There have been some discussions about shifting the end of the sprint in the past [1], and the general conclusion at the time was that it was not straightforward to figure out if another deadline would work better than the current one, as every solution tends to have a series of drawbacks – and the current thread gives me the same impression.

I agree with @adolfo about the fact that we likely wouldn’t be able to plan the sprint asynchronously in a single day – it was already quite difficult to fit in 3 days, and that’s not counting the preparation that should happen on epics & tasks ahead of the sprint planning itself. So unless we find a way to make it work in one day, we would need to find another way.

As @adolfo also rightly guessed, I do think that ending up with too much work on Monday, and not being able to do both the sprint planning & avoid spillovers is a symptom of an issue with planning earlier in the sprint. Yes, we humans tend to delay things until the last minute – but we are also able to learn and change our instinctive behavior when they are counter-productive. And as mentioned in this discussion, if there is too much left on Monday (or on week-ends) on a regular basis, then it’s a sign that too much work was kept for the end of the sprint. It’s hard to resist doing less early in the sprint – but our experience proves that doing that creates problems for ourselves, and that can be used as motivation for the first days of the sprint, by keeping in mind that those early efforts will pay back a lot at the end.

Personally, I tend to plan most of my risky, difficult or large work at the beginning of the sprint, and the enjoyment of the feeling of completing tasks calmly is a huge motivator. Moving the deadlines around might save week-ends or avoid getting multiple rushes at the same time on Monday, but it will still remain a difficult day if the work is done too late in the sprint.

That’s why I’m interested in the outcome of the research work suggested by @Fox – it could be interesting to consider how, when and for whom these issues happen, to see if there isn’t something more targeted that can be attempted – and which would help not having end-of-sprint rushes.

To address the fact that we currently have deadlines for both planning and the sprint tasks on the same day, the suggestion from @Agrendalath could also be worth considering – it has the merit of being simpler than trying to add a planning day between sprints, and the solution would also push us to plan earlier: :slight_smile:

Ideally, we would have one cell try different options, and see what sticks. We could consider this, but the end of sprint deadline has a lot of dependencies and implications, as well as automation depending on it, so it’s also difficult to just try. If a cell is willing to test one of the proposed timelines, feel free to try it for a couple of sprints (assuming the corresponding planning checklist for these cell’s sprints can be modified manually in, and doesn’t require to change the automation in non-trivial ways), and then report on the outcome – we’ll probably have much more concrete data to take decisions then.

I’m not sure I would advise to try big changes right now though – we are still grappling with the many side effects of a long standing availability issue which is not yet fixed (though there are encouraging signs, confirming core members take time), and is already overloading us, in particular the core team members. Implementing larges changes would accentuate the issue imho, and create confusion and more work. I would suggest to work on researching & identifying the causes for now, maybe working on smaller improvements at first, and keep testing a bigger change for when the availability of the core team is restored – hopefully we’ll finally finish resolving this in the coming months. But that’s something that could be decided at the cell level.

[1]: For the previous discussions related to sprint deadlines, see these threads: and maybe a bit in )


By changing the template board’s ID and restarting the Crafty bot service, then closing the sprint and reverting the change in Crafty bot service combined with a restart, it can be done easily (from the integration point of view). If a cell want to do that, I can help with more specific info too.

1 Like