Latest Changes to the Asynchronous Sprint Planning Process

[nizar]

Hello @team! As part of the Capacity & process issues, there have been some refinements for the asynchronous sprint planning process we use at OpenCraft.

This post will summarize the latest changes to the asynchronous sprint planning process, so members are aware of the different refinements and have the chance of utilizing the refinements to improve their sprint planning.

Changes

Changes have been done to different parts of the sprint planning process and its checklists.

Sprint Planning Checklist

There have been some drastic changes to the sprint planning checklist.

Below, the changes will be covered. However, if you’d like, you can view the new Sprint Planning Checklist Template on Monday.

No Duplicate or Work-Ahead Tasks

All duplicate reminder and work-ahead tasks have been removed in favor of a single actionable-task which comes at the required deadline.

No More Timeframes

Time-frames where members have a specific period to work on their tasks have been removed.

Tasks now have a specific due date. However, you can always work-ahead on your checklist if that’s something you’re interested in.

Making Tasks More High-Level

Different low-level tasks have been combined into higher-level tasks which members can check-off at once.

Each task still has a description, which contains information about the different lower-level tasks, to help newcomers adapt to the sprint planning process.

Sprint Planning Checklist Views

A lot of members use different views in Monday. While many members use the “My Week” view in the sidebar, other members might prefer a Gant View, Kanban View, or a Table View without the description.

Below are the new views added to the Sprint Planning Checklist Template along with screenshots.

You can find these views below the checklist description at the top of the page, directly above the “New Item” and “Search” buttons.

In case you like any of the boards shown below, you can set it as your new default by clicking the three dots next to the tab’s name and, then, “Set as board default”.

No Description Table View

Based on the request of some members, a new “no description” table view has been created to only show the necessary columns.

Kanban View

For members who prefer a kanban view, you can now “drag-and-drop” items based on their progress.

The kanban boards are separate for each week, which might not be to the liking of some, but that can help distinguish the different deadlines.
Also, combining them all in the same board isn’t possible in Monday.

Gant View

For members who prefer a gant view to keep up with their duties, you can switch to the “Gant View” tab and utilize that.

Sprint Planning Process

More Time Reserved for Planning

Previously, members were having trouble with their sprint planning. Accordingly, tickets were created for members to reserve the time they need for sprint planning.

Although things were working out great, eventually the sprint planning time was reduced. Alongside with some unexpected adhoc requests or under estimated tickets, sprint planning wasn’t done as effectively.

Therefore, we have archived these recurring tickets and added the time to Sprints, instead.

Previously, Sprints only reserved 2 hours for catching up with forum threads during the asynchronous sprint planning process. The time reserved in Sprints, now, is 8 hours. These hours are to be utilized for sprint planning and catching up on forum updates.
For example, my commitment per sprint is 60 hours. Previously, Sprints would show 58 hours as the “Goal”; instead, now the goal is 52 hours.

These 8 hours might not all be used, but they provide a good fail-safe to ensure members have time to plan their future sprint.

Although some members might consider 8 hours too excessive for their sprint planning, it’ll remain possible for members to work-ahead on tickets. Members can coordinate with the epic owner to split large tickets or time-box large tickets during a specific sprint.

Monitoring

In order to ensure the changes are effective, it’s essential to monitor the usage of the sprint planning checklists and the sprint planning among cells. A recurring ticket has been created for that purpose (please do not log the time reading this onto that recurring ticket).

Monitoring Sprint Planning Checklists

In order to monitor the sprint planning checklist usage for all cells, the following dashboards have been prepared on Monday.

• Serenity Sprint Planning Dashboard
• Bebop Sprint Planning Dashboard
• Falcon Sprint Planning Dashboard

In case members are not using their checklists, tickets will be required for these members to fill-in a form to provide clarification regarding why the checklists aren’t being used.

Monitoring Sprint Planning Among Cells

In order to monitor the sprint planning among cells, the follow different aspects will be observed…

Estimation Session Participation

The number of members who participated in the estimation session will be collected. In addition, the number who finished estimating all tickets will be collected.

Finally, the number of estimated tickets and the total number of tickets in the session, both, will be collected.

Synchronous Cell Communication

The asynchronous sprint planning process, when done properly should significantly reduce last minute planning and synchronous communication.

This will be collected by retrieving the number of cell members pinged during the final day of sprint planning, in each cell.

Amount of Sprint Planning by Monday

Increasing the time reserved for sprint planning is to ensure members have the chance to prepare all their tickets before the final day of the sprint planning, Monday.

Accordingly, first thing on Monday, information should be collected about the commitment of members for next sprint, while ignoring spillovers.

The number of members who have already committed at least 70% of their goal, per sprint, with new work will help determine whether members are able to plan their sprint ahead of time, or not.

Future Prospects

The results of the monitoring will be collected and shared after 3 sprints with the team at OpenCraft.

Based on these results, decisions will be taken on whether additional changes are needed for the sprint planning process.

I already have plans to target some refactors in mind for the sprint planning process, but they are on hold until all members can get their sprints back to normal.

Hopefully, the changes described in this post will members with their overcommitments and their sprint planning.

---

Please be sure to use the sprint planning checklist for your sprint planning. It would help the whole team by providing more data regarding the sprint planning.

[ Ticket to Log Time — SE-4914 ]

[antoviaque (Xavier Antoviaque)]

@nizar This is great work. Thank you, one more time, for the care and energy you put into improving the processes. And the metrics you have chosen to monitor the effect of the changes seem sound to me - I’ll be curious to see where that gets us.

[anon46505572]

@nizar

Although some members might consider 8 hours too excessive for their sprint planning, it’ll remain possible for members to work-ahead on tickets

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. ¯\_(ツ)_/¯ (this is a joke to demonstrate how we need to be careful about how we implicitly block hours here.)

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. 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…

@nizar

Therefore, we have archived these recurring tickets and added the time to Sprints , instead.

Note that Falcon was not using these recurring tickets, so for us, it throws off current assumptions.

[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 (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 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.

Explicit is better than implicit.

~ The Zen of Python

[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.

[antoviaque (Xavier Antoviaque)]

Maybe the crux here is that it has just been missing some prior discussion and agreement? We more or less picked 8h arbitrarily, without talking it through – it might just be surprise? Maybe the 8h mark could be adjusted? There is definitely a balance to find; reducing the amount of work one can take in a sprint also has drawbacks, just like keeping too much in it, so we need to figure out what the right number is.

@nizar

If you have the chance, discussing it synchronously would be awesome.

Can we keep this kind of discussion public?

[anon46505572]

@nizar

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

Yes that was a joke.

@antoviaque

We more or less picked 8h arbitrarily, without talking it through – it might just be surprise?

Yep the surprise of this was really irritating. It wasn’t discussed, and Sprints didn’t give any indication that suddenly 6h more per member was blocked.

I don’t really care what we end up doing, except that the solution must be visible. If Sprints is implicitly blocking hours, it must display that to the user. It also must be clearly documented.

Otherwise it’s just a form of social engineering, which will be (and already is) worked around by members that figure it out.

[nizar]

@antoviaque

Maybe the crux here is that it has just been missing some prior discussion and agreement? We more or less picked 8h arbitrarily, without talking it through – it might just be surprise? Maybe the 8h mark could be adjusted? There is definitely a balance to find; reducing the amount of work one can take in a sprint also has drawbacks, just like keeping too much in it, so we need to figure out what the right number is.

We definitely need to “fine-tune” the value.

Monitoring the sprint planning will make that possible.

@antoviaque

Can we keep this kind of discussion public?

Sure

If it’s discussed synchronously, I’ll be sure to provide a recording/log and an overview.

@anon46505572

… the solution must be visible. If Sprints is implicitly blocking hours, it must display that to the user. It also must be clearly documented.

I understand the need for documenting the changes. I created a task to do so.

[antoviaque (Xavier Antoviaque)]

@nizar

@anon46505572

… the solution must be visible. If Sprints is implicitly blocking hours, it must display that to the user. It also must be clearly documented.

I understand the need for documenting the changes. I created a task to do so.

On the topic of making the blocked hours more apparent, note that @Ali has just designed a set of mockups to rework the sprints interface: https://invis.io/MH11UUWGU3WQ#/459604574_Landing_Page – it might make sense to comment there to make sure that this use case (and likely the related use cases for which we create recurring tasks currently but would like to move to sprints) is properly handled and displayed in that new interface.

I’ve posted a comment about this – don’t hesitate to also comment there.

[Ali]

@antoviaque

@Ali has just designed a set of mockups to rework the sprints interface: https://invis.io/MH11UUWGU3WQ#/459604574_Landing_Page – it might make sense to comment there

Thanks @antoviaque. This would be helpful.

[gabriel (Gabriel D'Amours)]

@Ali the mockups look amazing, very nice work

[anon46505572]

@nizar

I understand the need for documenting the changes. I created a task to do so.

Not just documenting the changes, but making them visible. If I’m looking at my line in Sprints, I want to see right away how much time has been implicitly or automatically blocked.

These new designs look lovely btw! Keen to see continued improvement to the app.

[nizar]

@anon46505572 ideally, the “goal” would remain our weekly commitment, which in my case is 60 hours. And the auto-blocked time would appear inside of sprints under my user’s dashboard.

That would make these changes “visible”. I’d be happy to make such a change, until the new interface is implemented. But I’ll need @Agrendalath’s approval first.

[Agrendalath (Piotr Surowiec)]

@nizar, where could we add these hours? To the Commited column? We should think about this change in the context of new designs - I believe there is not much value in editing the current frontend when we’re planning some pivotal changes.

[nizar]

I don’t want to add anything to the designs @Agrendalath. Mainly, I want to adjust the “committed” and “goal” to include the reserved hours.

Before:

After:

And then, in my user’s personal board, I see the following:

It’s a minor change that would align with the current work at the moment, and can align with any design changes. It would require a small change, which would be assigning a key to any “automatically blocked” time so that it can appear in the list of commitments for next sprint.

Let me know please your thoughts and if you have any concerns.

[Agrendalath (Piotr Surowiec)]

@nizar

It’s a minor change that would align with the current work at the moment, and can align with any design changes. It would require a small change, which would be assigning a key to any “automatically blocked” time so that it can appear in the list of commitments for next sprint.

I can see two ways of doing this:

1. Creating an artificial DashboardIssue for each user. This is going to be very hacky, as we need to manually fill each field that is normally provided by Jira. We will also need to ensure that it doesn’t break the Budget and Sustainability board, as Jira requires each ticket to have an Account set We might have already taken it into account, as subtasks can inherit accounts (thus not having any value there), but I don’t remember this now.
2. Adding a serializer field to DashboardRowSerializer, so we can pass the reserved time and create an artificial issue on the frontend, extending user_issues before generating the UserTable. This should be a bit easier, but still hacky.

My concern here is - we are trying to think of a hacky workaround, instead of relying on an out-of-the-box solution provided by Jira - recurring tickets. I understand that we want to enforce some specific time for each member, but by doing it like this, we are increasing the technical debt. This is a feature that is specific to our workflows, and it’s not future-proof. That’s why I was asking how we should represent it in the new designs - if we find a way universal way of representing this, then it won’t come back to bite us in the near future.