Latest Changes to the Asynchronous Sprint Planning Process

[nizar]

@anon46505572

I’d like to tongue-in-cheek propose that we increase this up to 60h per sprint. This will eliminate spillovers as there will be no tickets in the current sprint, resulting in an elimination of stress. Members can always work ahead on tickets all sprint. ¯_(ツ)_/¯

I’m not sure if you’re joking or not.

But I’m hoping to reduce the stress by changing the ticket creation cut-off and the ticket scheduling process.

But that’s a discussion which will require a lot of efforts and cannot be started in this thread.

@anon46505572

Seriously though, I’m not a fan. 8h is more than a full day’s work that Sprints effectively steals from you at the start of the sprint, all without you realizing. The “remaining” value is now less meaningful.

Sprints isn’t stealing anything from you.

Members are expected to fulfill their sprint planning responsibilities. Every member has a recurring task to plan their sprint, which includes a bunch of subtasks.

Instead of creating recurring tickets, such as the FF tickets you suggested removing, Sprints is auto-blocking time for sprint planning.

Also, you don’t get paid for the time that shows in the Sprints. You get paid for the time you log… If you feel like working more during your sprint and that you finished things as expected, without utilizing the error margin added, you can pick up more tickets.

@anon46505572

If Sprints is going to manipulate the maths more, then members will start manipulating the maths too to be be able to take the normal amount of tickets without appearing overcommitted…

Previously, on top of their actual work, members had sprint planning responsibilities which were not accounted for.

The whole purpose of blocking time for members to plan their sprints is so that they aren’t over committed by reducing the amount of work they are picking up.

If members choose to “cram” some additional tickets, they are sabotaging themselves, the cell, and OpenCraft.

Anyway, in case members do that, it’s because the current process indirectly enforces on the whole cell expectations. I have a huge issue with this, and I’m hoping to change it by targeting the ticket creation cut-off and ticket scheduling process.

I read more about SCRUM, and what I understood is that sprint planning managers or SCRUM masters discuss with the development team the expectations based on the development team’s capacity.

However, the current process of scheduling work for the next sprint indirectly enforces the tickets scheduled on all the members of the cell. Sure, moving the tickets out is possible, but members are not properly portraying their commitments.

This is due to the current process of enforcing the clients’ expectations on the cell, instead of giving the developers the work they have capacity for.

But this change is extremely large, and I can’t do it properly and take my time with it if members are still under pressure. I’m just trying to alleviate some of the stress on the members in order to properly address the main issue. This will seriously help members breathe, while a proper change is being prepared.

@anon46505572

I’d like to instead seriously propose that we update the guidelines for allocating time for planning. We currently have recommendations for where to log time, but not where to increase estimates to account for time (thanks @jill for this thought). Either way, we need to standardize the docs and recommendations to avoid confusion

Yeah, we definitely need to update the guidelines for allocating time you need, for any reason, not just sprint planning.

We also need to convince members to do so, because some members might feel like they are “cheating” or “lying”. It should be conveyed that doing something like that is acceptable.

For example, @jill once mentioned that it’s acceptable to move my work out of my sprint if I spend more time on firefighting than the hours already reserved by the firefighting tickets.

That should’ve been mentioned explicitly elsewhere. It might have been, but the documentation is WAY TOO OVERWHELMING for me to even remember such a detail.

@anon46505572

(for example, an idea going around on the forums recently was to always ensure you were undercommitted, but if Sprints already ensures you’re effectively 8h undercommitted, then any more undercommitment will be excessive).

I agree, those two recommendations should be mentioned in the same place to avoid confusion.

However, that’s a little less priority because it’s not something as severe as over commitment. There’s always work for anyone under committed, and they can always pick up additional work.

However, over commitment is much more severe and serious because it affects the person and the company.

@anon46505572

I also would recommend being explicit and visible with blocking or reserving time on Sprints. For example, I would prefer members explicitly ensured they stayed undercommitted by X hours if they prefer, rather than having Sprints implicitly block hours. Or if we need a catch-all place to block X hours for misc tasks that we aren’t normally accounting for, maybe provide a per-member value in Sprints that is visible and can be adjusted by members whenever.

Not yet.

I don’t trust the current ticket scheduling process.

We’ve already done something similar by creating the recurring “sprint planning tickets” in Serenity.

When I reserved 6 hours for all members, for 3 sprints, absolutely no synchronous discussion or sprint planning management was necessary. All sprint planning, by all members, was done by end-of-day Friday!

When I gave members the chance to reserve the time they find fit, between 2 and 4 hours, things just did not work out. Sure, the sprint planning is definitely okay… But, once in a while a member under estimates their tickets in order to fit in more work because of the current ticket scheduling process.

For now and for the sake of the members, I’m not comfortable with that.
Under commitment is not an issue… There’s always work, especially for core members.

Although auto-blocking time for planning reduces the accuracy of one’s commitment, it helps reduce stress, reserve some mental capacity for members, and reduce their burn out.

At the moment, a single mistake with the estimates snowballs and ruins many sprints to come, for the member and/or their peers in the same cell.

That’s a trade I’m willing to make, for now. Until the process is more friendly towards members. Once the process is more friendly, then I’d be happy to give members the flexibility of adjusting the time they’d like to reserve for misc tasks.

---

Also I’d like highlight an amazing reply from @daniel, on a previous thread.

@daniel

It’s nice to say, but self-management is there for other reasons (as an alternative to middle managers), and we don’t have something like that to address health (to the contrary: being sick one day means you’ll probably need to recover the work and you’ll have a higher risk of spill-over). From what I know, the focus is rather on keeping commitments (and finishing sprints without spill-overs) and high quality.
Focusing on health would mean being able to say „I don’t feel like working on these tasks today; I need rest“ and being actually able to do it, without any consequences, other than not being paid for that work you didn’t do. In an organization where each person knows how to do many roles and is remote, that’s probably possible, but that’s another topic. But for now, I see that people’s focus has always been on finishing commitments, not on just doing X hours per week.
All this is my opinion only, about how it could be; and I’m brainstorming, and sorry if it’s a bit off-topic.

It would also be great if all tasks were correctly estimated, including unknown incidents/requests and sprint injections, so that you plan X hours and they actually take X hours. I hope we can learn more about that or measure how well the numbers match the reality. We could start by asking whether initial commitments are matching the reality.

This is a serious issue. I hope it is evident…

I might not be able to solve it with this change, but I intend to. It’s just a matter of time…

If I were in @daniel’s position, I don’t know how long I would be able to last…
So, I can’t expect the members to wait for a solution while suffering from over commitment.

I understand your comments on the situation. On the long term, I agree with them. But on the short term, I’m sorry but I don’t. I hope my justification convinces you of my stance.

If it doesn’t, I’d really love to further discuss this. If you have the chance, discussing it synchronously would be awesome. Let me know. Otherwise, we can continue discussing it on the forum, whenever possible.