Re-organizing the Sprint Planning Checklist tasks to eliminate redundancies

As many of you might already know, or have already experienced, we use a Sprint Planning Checklist in order to handle our sprint planning process and ensure that our responsibilities towards the whole cell are fulfilled/met.

Our current sprint planning checklist at this time can be found here.

Over the last couple of sprints, there’s been a couple of tweaks thanks to the automation bebop cell members have worked on, which are:

  • Automated Estimation Sessions
  • Automated Sprint Injection Tracking

This has helped reduce some items in the sprint planning checklist. In addition, a monday.com discussion about removing the redundant “working ahead” tasks lead to some further changes and updates to the sprint planning checklist.

In order to provide an idea of the changes, here’s roughly what changed:

  • Shorter task titles
  • No more “work ahead” tasks
  • No more repetitive tasks
  • Strict deadline tasks instead of long timeframes
  • Different ordering/grouping of tasks
    • Ordering by Week
    • Ordering by Deadline

Accordingly two different identical boards were created, with different styles of grouping:

It is also important to share a small diff of the task descriptions because some of the task descriptions were merged under the same headline.

-Address the last review comments about tasks s and scopes. Once satisfied and any outstanding issue revealed by the estimation session are resolved, remove the flag on the ticket.
-Check if you are overcommitted, and if so pass on tasks to people with room, or further reduce/split the scope of your tasks as necessary. (extra "overcommitted" check)
-Ping other potential task assignees on the tasks you have assigned or been assigned on (especially arbitrarily), as well as potential reviewers
-Pre-assign all tasks that need to be included in the upcoming sprint at least tentatively (arbitrarily if needed) and - assign CAT-1 priority to them to mark them as required for next sprint. Flag tickets to mark them as tentatively assigned. To flag a ticket, right-click a task from the backlog or sprint view and select "Add flag".The ticket will then appear in orange in the backlog. Or when Editing a ticket, tick the Impediment checkbox
-Finish to create & move tickets to the upcoming sprint.   Thursday of week 2 is the ticket creation cutoff, no ticket created after the end of that day can make it in the upcoming sprint, except as described in task insertion.
+Finish to create & move tickets to the upcoming sprint.   Thursday of week 2 is the ticket creation cutoff, no ticket created after the end of that day can make it in the upcoming sprint, except as described in task insertion.  Pre-assign all tasks that need to be included in the upcoming sprint at least tentatively (arbitrarily if needed) and - assign CAT-1 priority to them to mark them as required for next sprint. - Flag tickets to mark them as tentatively assigned. To flag a ticket, right-click a task from the backlog or sprint view and select "Add flag".The ticket will then appear in orange in the backlog. Or when Editing a ticket, tick the Impediment checkbox
-Review tickets assignations, especially arbitrary ones, for assignations you need to pass on to someone else. It can be due to lack of available time or interest, no justification is required to pass it on. Though until and unless the ticket is reassigned, that person is still responsible for reviewing the ticket  in the meantime, and for helping to find a new assignee in time. To ensure that no task is left without a reviewer at that stage, the assignee is only changed once a new assignee is found, or the epic owner has agreed to postpone the task.
-Review the  of the tasks you are assigned to (even arbitrarily), to ensure they match the Tickets s standard, asking for changes in the task comments as needed. If changes are needed, set or leave the flag on the ticket, to indicate it needs work.
+Review tickets assignations, especially arbitrary ones, for assignations you need to pass on to someone else. It can be due to lack of available time or interest, no justification is required to pass it on. Though until and unless the ticket is reassigned, that person is still responsible for reviewing the ticket  in the meantime, and for helping to find a new assignee in time. To ensure that no task is left without a reviewer at that stage, the assignee is only changed once a new assignee is found, or the epic owner has agreed to postpone the task.  Review the  of the tasks you are assigned to (even arbitrarily), to ensure they match the Tickets s standard, asking for changes in the task comments as needed. If changes are needed, set or leave the flag on the ticket, to indicate it needs work.
-Set the “Remaining” estimate on each ticket - Review/adjust the "Time Remaining" estimate for every story of yours still in the sprint current.  - Check the sprint planning dashboard for any tickets in the "Unestimated" column and set a remaining estimate for them.
-Start creating new tickets for the next sprint, and adding them to that sprint and to the estimation session.
-Update your tasks assignments (including reviews), to take into account the estimates. On the sprint planning dashboard, Check that the "Committed" and "Goal" columns on the sprint planning dashboard match your expectations, and that you have committed all your hours for the upcoming sprint without overcommitting.
-Work ahead on items listed for Monday as much as possible, to leave only the strict minimum for Monday, i.e. items that are still blocked on others at this point.

I’d love to hear what you think about the new boards and to know which of the boards you prefer.

  • Week Grouping
  • Deadline Grouping

0 voters

[ Log Time on SE-4155 ]

1 Like

Thanks for looking into this @nizar . I have a few questions:

What is the goal of that change? There is definitely a timeframe of several days for doing some of the tasks – and actually changing from just deadlines to timeframes was a change based on feedback, that there was too much to do on some of the days - we want to encourage doing the work as early as practical, rather than cramming everything on the deadline day. Reverting this would push towards the opposite.

Also, when using the gantt view, isn’t it helpful to see what can be done on the current day, instead of just the deadline itself? The latter provide less information, and ways to sort out the tasks?

Actually, seeing the next change makes me wonder why we don’t standardize around the gantt view, rather than the default table? Would this make the choice between these two views moot?

Ie, with the gantt view, you get to see both, ie the tasks doable on a given week, or a given day?

Also, for the items that are being removed – some of them make sense and are probably superfluous, like the work ahead ones. Although, it would also go in the direction of less encouragement to work before the deadline – imho if these get removed, it becomes even more important to keep a range for the timeline on each item, to show clearly that they are meant to be worked ahead on.

For some of the others, have we carefully considered the effects of removing them? I’m not copying all of the items, but for example:

-Address the last review comments about tasks s and scopes. Once satisfied and any outstanding issue revealed by the estimation session are resolved, remove the flag on the ticket.
-Check if you are overcommitted, and if so pass on tasks to people with room, or further reduce/split the scope of your tasks as necessary. (extra “overcommitted” check)
-Ping other potential task assignees on the tasks you have assigned or been assigned on (especially arbitrarily), as well as potential reviewers
-Pre-assign all tasks that need to be included in the upcoming sprint at least tentatively (arbitrarily if needed) and - assign CAT-1 priority to them to mark them as required for next sprint. Flag tickets to mark them as tentatively assigned. To flag a ticket, right-click a task from the backlog or sprint view and select “Add flag”.The ticket will then appear in orange in the backlog. Or when Editing a ticket, tick the Impediment checkbox

If people stop doing this type of steps, wouldn’t this break the process, or at the minimum create more work for sprint planning managers to chase people to do these?

And even if existing core team members remembered to do these without being reminded, how would newcomers know to do any of this in the first place, if this isn’t in the process description and steps? emember that this is also our primary source of truth and documentation about the sprint planning process.

I’m really sorry about this late reply. Too many fires this sprint!

Yeah that’s a great point.

Although people who want to work ahead can work ahead on the tasks, the checklist should indicate that it is possible to work ahead on stuff by specifying a timeframe instead of just a deadline.

This also helps with the “My Week” view.

I added them back :+1:


Actually, seeing the next change makes me wonder why we don’t standardize around the gantt view, rather than the default table? Would this make the choice between these two views moot?

I love this idea, but the only reason I think twice about it is because monday.com’s UI feels laggy.
But yeah, it’s more useful to provide a Gantt Chart than struggle with organizing the checklist in groups.

Also, yeah we would just then be able to group them by week in the actual table, since a better detailed view would be possible in the Gantt Chart.


For some of the others, have we carefully considered the effects of removing them? I’m not copying all of the items, but for example…

Yeah, I thought about it and I agree. The points you highlighted are the ones I couldn’t remove to be honest, because they feel important as a documentation for the process.

“Check if you are overcommitted” Task

- **Check if you are overcommitted, and if so pass on tasks to people** with room, or further reduce/split the scope of your tasks as necessary. (extra “overcommitted” check)

Although I removed this task, it was a duplicate. There’s another task identical to this one.

“Pre-assign all tasks” Task

- Pre-assign all tasks that need to be included in the upcoming sprint at least tentatively (arbitrarily if needed) and - assign CAT-1 priority to them to mark them as required for next sprint. Flag tickets to mark them as tentatively assigned. To flag a ticket, right-click a task from the backlog or sprint view and select "Add flag".The ticket will then appear in orange in the backlog. Or when Editing a ticket, tick the Impediment checkbox

Although I removed the task mentioned above, I added it’s description to another task, which is shown below.

Finish to create & move tickets to the upcoming sprint.

Thursday of week 2 is the ticket creation cutoff, no ticket created after the end of that day can make it in the upcoming sprint, except as described in task insertion.

Pre-assign all tasks that need to be included in the upcoming sprint at least tentatively (arbitrarily if needed) and

  • assign CAT-1 priority to them to mark them as required for next sprint.
  • Flag tickets to mark them as tentatively assigned. To flag a ticket, right-click a task from the backlog or sprint view and select “Add flag”.The ticket will then appear in orange in the backlog. Or when Editing a ticket, tick the Impediment checkbox

“Ping other potential task assignees” task

It seems like I forgot to include that in one of the descriptions, so I just added it to the task mentioned above, which makes it:

Finish to create & move tickets to the upcoming sprint.

Thursday of week 2 is the ticket creation cutoff, no ticket created after the end of that day can make it in the upcoming sprint, except as described in task insertion.

Pre-assign all tasks that need to be included in the upcoming sprint at least tentatively (arbitrarily if needed) and

  • assign CAT-1 priority to them to mark them as required for next sprint.
  • Flag tickets to mark them as tentatively assigned. To flag a ticket, right-click a task from the backlog or sprint view and select “Add flag”.The ticket will then appear in orange in the backlog. Or when Editing a ticket, tick the Impediment checkbox
  • Ping other potential task assignees on the tasks you have assigned or been assigned on (especially arbitrarily), as well as potential reviewers

If people stop doing this type of steps, wouldn’t this break the process, or at the minimum create more work for sprint planning managers to chase people to do these?

You’re right, if people stop doing the steps, we won’t benefit. But what I’m trying to do is decrease the steps and expand the documentation about it.

So instead of having a lot of subtasks regarding a specific item, move that into the description or documentation of the task.

Let me know though if you disagree, maybe we can try approaching this with the Workflow Manager instead, since it would have documentation, and not just a description box.

And even if existing core team members remembered to do these without being reminded, how would newcomers know to do any of this in the first place, if this isn’t in the process description and steps? emember that this is also our primary source of truth and documentation about the sprint planning process.

I didn’t intend to delete anything important. The main reason I shared the difference in the task descriptions is so that members can call me out in case I deleted something important.

I’ll wait to see your thoughts about moving the details out of the actual tasks and into the task description. And I’ll either proceed with the changes or revert them :+1:

@nizar I’m happy to let you experiment with this, and figure out what’s the best middle ground between too many checklist items, and too little.

I would just ask to validate the changes by:

  • Checking after the changes what were the consequences in terms of sprint planning manager workload, number of steps that were missed and quantity of synchronous chat coordination that ended up being necessary to finish preparing the sprint
  • Verify the effect of the changes on newcomers, too - to see if they end up missing more things, or have trouble understanding some parts of the process
  • As much as possible, starting by experimenting it in one cell, rather than everywhere all at once - so it doesn’t disorganize the whole company at once if the changes create unforeseen issues. It would probably be sensible for the sprint planning manager of the cell doing the experiment to plan for more coordination time during the sprint where the change is implemented.

Does that work?

1 Like

Sorry for the insane delay in replying. This has been pretty low priority for me, since I’ve been focusing mainly on the Workflow Manager work.

It seems, unfortunately, that I’ll need to continue working on this epic and focusing on it as one of my own since no one has any capacity to pick it up.

Thank you :smiley: I really appreciate it!

Yeah, sounds good. I think before changing the checklist then, I’ll need to prepare a decent form on google forms to collect the answers of sprint planning managers.

This is going to make things a little bit tougher, but it is definitely possible.

We might need to re-discuss the budgets though, since it seems like both the Workflow Manager epic and the Sprints Planning Checklist epic are staying in Serenity because no one else has the capacity to work on them.

Should I schedule a ticket for that? I’m expecting your sprint to be fully packed, so I was thinking of scheduling something for SE.244b. Let me know please :+1:

@nizar Sounds good!

Note that, besides the changes that you describe here, if you want to take care of handling them, the future changes can wait for the new cell/owner to take it over. If it’s an availability issue, you can still agree with someone who would take it when they get the availability, and in the meantime it’s paused, with maybe just a feedback thread or document where suggestions of improvements or requests can be collected in the meantime.

As for the discussions with the sprint planning managers, since it’s only 3 people so far, a form might be overkill :) Maybe just discuss it between you, scheduling a task to allocate time for it explicitly?

@antoviaque yes I might need to prepare the document with the future plans and have someone else pick up the epic instead of me, with the discovery that I would’ve done.

Sure, scheduling 121 meetings would be much easier :+1:

I’ll post future updates next sprint about the progression (even if very minor).

1 Like

@nizar Thanks!

Btw, for “discussing it together”, I didn’t necessarily meant meetings :slight_smile: Sometimes that can be a good option when a lot of back & forth would be necessary otherwise (just keep it public by posting a recording), but this could also be a discussion between the three of you here, for example.

1 Like

Small update on this thread; I have created a planning ticket to plan a short flexible phase 4 until the epic can be passed on to a new cell.

There are 3 tickets planned, at the moment:

  • Adding current and next sprint firefighter context to the checklist
  • Adding multiple checklist templates in Crafty bot
  • Reorganize the sprint planning checklist tasks to eliminate redundancies
1 Like