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

Discussions - Public
1

Hi @team. We at Bebop often struggle with a number of issues. I’ll list them.

Hectic end of sprint, and poor planning as a result

Humans have a natural tendency to delay doing work until the deadline, especially when stressed.

At OpenCraft, commitment is a core value, and team members are trying to deliver the maximum amount of work before the end of the sprint. That’s why every cell member sometimes has a lot of work to do on the Monday of a third sprint week, right before the end.

However, we also start the next sprint right after the completion of the previous sprint, and we have to plan it properly. The planning process itself is energy consuming, and as a result, we have the problem of experiencing two sources of stress on a single day.

image
image853×447 27.6 KB

I suspect that this is even worse for newcomers, since they are required to have no more than two sprints with a spillover during their trial. So, they often can’t do their part of the planning work, which put additional stress on sprint planning manager.

Working on weekends

Another problem is that weekends act as a “safety margin,” and team members who had unproductive days in the sprint use them to catch up. That leads to stress build up and the need to take a vacation at some point.

For example, I often find myself worrying about some work that I need to spend time on during weekends. Obviously, that’s problematic and makes proper mental recovery impossible.

Poor sprint retrospectives

One more, not obvious but significant, problem is poor quality of sprint retrospectives. When our meetings were synchronous, we often had extensive discussions about how the sprint went. But now, due to the above-mentioned reasons, people don’t have the time to fill a retrospective spreadsheet, and now it feels like a formal and optional thing to do. But in fact, it is one of the key SCRUM processes, which by design should be the source of innovations in our processes.

Solution

I propose moving the end of sprint to W2, Friday 23:59 UTC, so weekends and W3 Monday will be between sprints. This way, we can avoid combining planning with wrapping the sprint up and, in theory, greatly reduce stress levels and prevent people from working on weekends.

image
image950×510 35.6 KB

We can conduct an experiment in the Bebop cell and try to work like this for a few sprints, starting from BB.251. Luckily, we measure stress levels and have collected a good amount of statistical data, so we would be able to compare values and make a final decision based on outcome.

What do you think?

[ Ticket to log time spent reading and answering. ]

2 Likes
2

While I agree with most everything you wrote, this is the main downside with the proposal: it would effectively remove a day from the sprint.

Now, a day’s worth is what it takes me, for example, to properly plan a sprint, both as developer, epic owner, and everything else. So if we could elect to have the last Monday officially be Dedicated Planning Day, effectively moving all planning to that day, and that day only, I would be onboard with the proposal.

But… Can we do that and still do things asynchronously? That’s the catch.

2 Likes
3

And I can tell you what Xavier is going to say about this one:

Plan ahead instead. ;)

1 Like
4

Also (sorry for the pile-on), any reason why this can’t be a public discussion?

5

I’m generally in favor of this but would like to volunteer an alternative: why not move the start of the next sprint to Wednesday instead?

My rationale for this is that it achieves the same thing (1 “dead” day between sprints), with a major difference: you can catch up over the last weekend and have someone review on Monday.
One of the good things about our processes is that we’re allowed flexibility but, IME, what ends up happening is:
Week 1: “I don’t need to work during weekend 1 because things are going ok, just relax”
Week 2: “OMG this is taking much longer than expected but… it’s no use catching up on the weekend because nobody will have time to review on Monday” (true story)
*gets spillover*

I know some people feel like this encourages working in the weekends but I don’t agree with that: the whole reason we do detailed planning like we do is to make sure things line up correctly.

With regards to the retrospective, I don’t see the issue as being due the timing for sprint starts and endings but more due to not having time blocked for it (which is implicit in sync meetings): if you don’t contribute, it doesn’t count as spillover, so you focus on the things that do.

6

That’s true. But those who want, will be able to start working on tickets from the next sprint in a relaxed pace. We are obliged to deliver work before some deadline, but I see no reason to tie the start of working to some point of time.

Oh, thanks for noticing this. I misclicked the item in the dropdown. Changing.

IMO, working over the weekend is already a bad signal. So, if you get a spillover as a result, I think it’s a good thing because in this case, the metric represents the problem: in planning, in circumstances, or in person. By stressing yourself out with working over weekends, and making someone review your work last minute, you just hide the problem.

Though, I would agree with any option that implies “dead” day.

7

Sure, but we’d be removing 10% of the cell’s nominal capacity while doing so,
unless all planning happens during that day and no other day. I like this idea, but I fear 24h will not be enough for asynchronous planning. I might be wrong, though.

IIRC, the whole reason the end of the sprint was moved to Monday was to give people time to finish work on weekends. But as you point out, that doesn’t really work too well because nobody has time to review on Monday. So if we moot the Monday argument, the natural option would be to move it back to Friday - which at the very least solves one of @demid’s stated problems: that of not being able to rest on weekends.

To be clear, if we’re moving the end of the sprint, I agree with Demid that it should be to Friday. I just don’t think that having a skip-Monday is realistic.

PS: I like skip days. I’ve nominally taken Fridays off for over month, now, which has given me a lot more peace of mind due to the reduced commitments (plus the fact that I end up working most Fridays anyway :P). But this reduction in capacity, and thus in guaranteed salary, was my personal choice. I don’t think it would make sense to impose it upon everybody.

8

It could be (because you over-committed/planned badly), or it might not be (something unexpected happened or you intentionally rearranged your work week).
Xavier (and now Farhaan IIRC) have also rearranged their work week so that Saturday or Sunday are a working day for them.
Making weekend 2 a “dead-zone” just takes flexibility away and could push people into working late hours, which is worse for health.
The argument that people tend to delay doing work until the deadline also suggests that they won’t actually work ahead in the weekend.

9

Aren’t we already doing this? If I remember correctly, initially SE-2952 was reserving 6h per cell member, which effectively the same ~10% of the cell’s capacity. We practice a similar approach in Bebop, but in fact, as per Parkinson’s law, other tickets and late reviews often fill all time reserved for planning.

10

I think it’d still be a bad signal. It doesn’t have to be that someone is ‘at fault’ for it to be a bad signal. I think maybe it’s better to say it’s kind of like a “code smell”, not absolutely bad, but a thing to be taken as worrying if it’s encountered too often, and to be critically examined when it occurs.

If you’re rearranging your schedule once, the signal is there, but can be safely ignored if things go back to normal. If you keep rearranging your weekend, even intentionally, that signal will keep being sent and you’ll need to take it seriously, because the impact of constantly shifting schedules makes it difficult to perform deep work.

Also, issues do happen which cause a ticket to be late, and which may not have been forseeable with current methods. If these happen with any consistency, though, it’s an indicator that process improvements need to be made.

Last, while spillover should be avoided, I don’t think it should be avoided ‘at any cost’. There may be times when for sanity, we have to be late. But in those times, we need to be clearly communicative, mitigate the damage, and see what we can do to prevent repeat occurrences. That’s why we have the spillover spreadsheet-- to keep track of what happened and why, and give us a chance to form interventions when there are patterns.

Overall, spillover should be RARE, and in most cases doing a bit of work over the weekend to avoid it should not significantly contribute toward burnout because there should not be a habit of working during your off-days. Planning and communication can prevent most of this, but it does mean starting earlier. Maybe even blocking out specific times on your calendar to work on planning rather than ‘trusting you’ll have a good time later’.

This is the thing I’m concerned about with this solution-- I think maybe instead of trying to perform an across the board change, maybe we should look at the data instead and help specific team members that are having difficulty with structure with tailored interventions. Several members are doing well with the current method, but we do have a few that may need help.

The data may also give us a better idea why they may need help. Imagine, for instance, we found most of the issues happened within a specific time zone band. That might tell us that they are having much larger lag-time issues than other members. Or, we might find that newer members have it the worst, suggesting that we might need to add something to our onboarding to help them out with planning, like making a dedicated step in their training for creating ‘planning blocks’ of time.

@demid , what would you think about creating a task to review a couple of months of spillover and seeing how many incidents of weekend (or off-day-- some are doing that weekend Wednesday style arrangement) work come up per member to see if we can come up with a pattern or remedies?

4 Likes
11

@demid, I have some initial thoughts:

  1. How would ending the sprint earlier help with the cases when we are blocked by a lack of synchronous replies due to timezone differences? Wouldn’t it be more helpful, e.g. to change the ticket creation cutoff day to W2 Wednesday EOD, end the estimation session on W2 Thursday EOD, and plan the sprint commitments on Friday? Currently, the only possible planning day is Monday, because this is a day when ticket estimates are set. On Friday it’s already pretty clear how much time will be required for wrapping up tickets from the current sprint, so this would add more time for asynchronous replies. This way people who have completed all commitments from the active sprint would be able to work ahead on Mondays if their sprint is already fully planned. Currently, it’s not always possible, because some tickets can be pushed back at the last minute due to capacity/sustainability/other reasons.
  2. Would this change mean more Friday deployments? To move a ticket to “Deployed & Delivered”, the changes need to be deployed - this status indicates that there is no work needed for this ticket. Currently, many deployments can be done on Monday, so we have more time to address potential issues.
3 Likes
12

Yes, but spread over many days, not focused on a single one - which is arguably not possible if you want to do things asynchronously.

13

For far east timezones this is mid-morning on saturday. For mid timezones, it’s the middle of the night on friday. For last-minute required tasks, this is now late friday night or saturday morning - from my perspective, this change has the effect of making more work on the weekends.

It shouldn’t. Members shouldn’t be feeling so pressured to finish tasks that they need to work on weekends. Fine if you’re doing a ‘weekend wednesday’ or it’s some once-off urgent thing that really couldn’t wait until monday, but normally things can wait until monday.

Absolutely agree. :+1: Better also to get spillover instead of working weekends and burning out.

Personally I almost never work on weekends, even if there is a squeeze at the end of the sprint. (I wonder if it’s partly related to timezones; I know that if I get something ready for review by midday on my monday, it’s usually able to be reviewed by others in more western timezones before the next sprint starts on my tuesday morning. :thinking: Although then it’s still spillover if the review wasn’t an approval or deployments still need to happen.)

@demid what’s the data source of the “Burnout in early stages” and “Burnout vs Sprint 2.0” graphs?

I agree; this is a problem all round with things happening last-minute. I think this is more of a product of everyone doing planning last minute + the checklist deadlines aren’t optimised yet (I’ve seen drafts that @nizar has in progress, and it’s so much better). Ticket cutoff is thursday, so ideally, members would spend some time thursday and friday doing sprint planning, and then monday can be more relaxing. This is a habit building process though - maybe things like personal calendar events (eg. 3pm to 4pm friday is time for next sprint planning) etc. may help? I feel like we’re reaching the boundary where tools stop and personal discipline starts.

People absolutely do have time; it’s 5 minutes to jot something down in the spreadsheet. The difficult part though is building the habit to actually write something when you think of something for the sprint retrospective.

We definitely did the retrospective better in synchronous meetings. For every point that was noted, it was discussed and follow up action items were created. With current discussion, no-one is responsible for follow up, and it often doesn’t happen.

It’s at this point where you need to ping epic owners and reviewers to let them know that it’s going to take longer, and potentially spin off follow up tickets if scope increased. This is the importance of reasonable time estimates and timeboxes. It is difficult though; most of my spillovers are just that: it takes longer than expected, gets caught up in back and forth discussion, scope increases, etc. This isn’t something that can be fixed by changing which day the sprint starts though.

I do wonder about a ‘gap’ or ‘dead’ day in between sprints though. We’ve brought it up before but didn’t try it out. I wonder if it would be worth experimenting with.

5 Likes
14

I feel the same struggle so I am in favor of trying new stuff to fix that issue.

Why not have just a recurring ticket to block more time for sprint planning? Something close to one day, like 5 hours (maybe more) so that we will pick less work per sprint which should give us a little more space to organize our next sprint.

15

This pretty much captures my point: if you start something on the 2nd week of the sprint and it takes slightly longer and you have some back and forth in review, we’re talking +3 days, i.e. Tuesday to Friday… and I feel this is very hard to estimate; what I’m trying right now to avoid this is to start everything on the first week by making a short investigation and pinging the reviewer to say where I’m heading, but this leads to a lot of multitasking (e.g. yesterday I worked on 6 different issues)…

Another thing I’m going to try is working ahead on weekend 1, so all the dates move “to the left”: hopefully that means Thursdays and Fridays are left for reviews, sprint planning and whatever “work ahead” I can do.

My other life commitments don’t really allow me to start work early or work late into the night; I’m already getting up at anywhere between 6:00 and 7:30AM but usually only get to sit down for work at 9:00AM, and basically get off at around 18:00 or 18:30PM for the kids’ bath/dinner/bed blitzkrieg, which usually ends around 9:00PM…
I could also bring my weekly hour commitment down but that influences pay.
On the other hand, I have at least 4 hours of nap time over the weekend that I could use for work…
I’m not trying to play victim here or suggest my life is somehow harder than anyone else’s, I just wanted to give a clearer idea of where I’m coming from.

16

@toxinu In Serenity, we have this – the recurring sprint planning management ticket (SE-2952) has a subtask for every cell member.

I thought this was the case for every cell? If not, perhaps the cells that don’t do this yet could try it out for a few sprints and see if it helps, before moving on to more complex approaches.

1 Like
17

We also have this in Bebop. Plus, we have 2h for the meetings per sprint included in Sprints. It was added when we’ve had synchronous meetings, but we’ve kept it to reserve time for individual planning in the asynchronous process.

1 Like
18

That’s a good idea. I will create a ticket in the next sprint and share findings in this forum topic.

Usually, it’s already clear by W2 Wednesday which tickets should be in the next sprint, so, yes, I think we can experiment with the ticket creation cutoff day safely. Also, this can solve another problem with lack of estimates in Agile Poker.

Good points. Now, I’m not so sure if the benefits of moving the end of the sprint to Friday will outweigh these problems. Probably, it’s better to rethink the original idea after doing the investigation that @Fox has proposed.

Oh, that’s just my imagination. I added these graphs only to make my post not boring and to illustrate the idea. Though, if Tempo has convenient API, I will try to rebuild the same graphs based on real data.

2 Likes
19

IMO, it doesn’t, but it’s a little nicer than some other Jira APIs :stuck_out_tongue:
You can reuse the Sprints Jira library, but be aware that running bigger Tempo queries has broken our Jira a few times in the past. A reboot helps, though, so as we now have it in our internal infrastructure, it shouldn’t be such a huge deal as before.

Feel free to add me as a reviewer to this ticket.

1 Like
20

@demid, @Agrendalath, I haven’t yet gone through this thread in detail - will do so later, but have a suggestion to prevent Friday deployments. We can have the sprint end on Thursday at midnight, have Friday as a “dead day” when people are expected to plan their sprints and work ahead, if possible. The next sprint will start at 12 AM on the next Monday. With this, the sprint will be from Monday to EOD Thursday in the 2nd week.