Tackling sprints without enough tasks

[antoviaque (Xavier Antoviaque)]

Current sprint (313)

First thing first – how is the workload for everyone this sprint? I tried to check again Sprintcraft now, but it already only shows the upcoming sprint 314, so I thought I would ask. In particular, does anyone need any additional work?

Also, I still see a bunch of unestimated tasks! (Or needing re-estimation.) I thought I had asked clearly above, twice, to make sure that all your tasks are estimated. Please do so immediately when you see this - I see unestimated tasks in Sprintcraft for: @artur @tecoholic @kshitij @Cef @rafay @Agrendalath @ChrisChV @pooja @rafay @mtyaka

Next steps

I reply below to some of the outstanding items, but here is a general recap of the next steps based on the discussion so far. We need to:

Create a handbook MR with:

• The “last resort” process description:
  • Submission of tasks (where, which account to use), approval & prioritization
  • Process to use a task (notification, RCA)
• Checklist for cases where one doesn’t find enough work (steps to get more tasks from the current/next sprint, preconditions for usage of the last resort backlog, then last resort backlog itself)
• New steps for detection of lack of tasks:
  • Move deadline for estimation up
  • Check workload & estimations:
    • each sprint by sprint planning manager (check everyone has estimated all their tasks, and that the resulting estimate matches the cell capacity)
    • each month by epic planning manager (check workload on all epics, and that it matches the cell capacity - ie need to hire, or to preload more work)
    • => steps when undercommitment detected:
      • create tasks for epic owners to create more tasks (splitting more or working ahead), clean-up the tasks from their epics in the backlog
      • communicate with bizdev/Fox to get more work assigned
      • bring up the topic on the forum

And a few tasks to create and schedule:

• Test implementation of earlier deadline for estimation (@maxim)
• Create tasks for epic owners to create more tasks (epic planning managers)
• Populate the last resort backlog (all)
• Review/approve tickets in the last resort backlog (me)
• Ticket to improve sprintcraft assessment of workload for upcoming sprint (who would like to take this?)
  • Provide a better assessment of the workload available in tasks vs cell capacity; especially, factor in the time remaining in the sprint when assessing the workload for the upcoming sprint
  • Help ensure that tasks are estimated - ping assignees of incomplete tasks in an active or upcoming sprint without estimate, without time left in the estimate, or tasks that need to be re-estimated (see below - all tasks in the active sprint which are still incomplete on the second Wednesday evening?)
  • Also allow to assess current sprint’s workload after it has started - currently as soon as the sprint start, we can only see the next sprint; getting some kind of history of the status at the start of the previous sprints might be useful
• Ticket to refine the Serenity sprint checklist (@mtyaka or @gabor, with @Fox & me as reviewers)
• Ticket to update the epic owners checklist & reminders (see below - to assign):
  • dedicate time for tasks creation/split & advance planning each sprint,
  • refine tasks from their epics in the backlog, grooming or archiving them
  • moving as many tasks as possible of their epics from the backlog to stretch goals (or last resort backlog if there is no budget or it’s prospective work to get more work)

Edit - additional tasks mentioned later on, below:

• Tasks to improve the epic updates, and transition to better practices
• Tasks to cleanup the Bebop backlog, for the sprint planning manager

@tikr Would you have availability to write the handbook MR & create the tasks?

Generating more (or better) tasks

@tikr

we could start by having epic owners block out a bit more time for epic management each sprint so that they have room for planning further ahead?

@tikr +1 to do more to ensure this happens - though isn’t it already supposed to be the case? What could we do differently here, concretely?

@tecoholic

I would like to request the crafty’s reminder for epic-updates be changed to say “End of day Friday” instead of “End of day Monday”. I would say it should be done even for the current schedule. For clients with parallel JIRA board, doing epic update and reconciling tickets between the boards usually happens at the same time. Making sure Epic update is done before Friday ensures any new tickets on the client’s board makes it into our internal board.

+1 - I have included this in the list of tasks above.

@sid

Right now, if I open the backlog (unassigned) list, I’m not sure how many tickets can actually be pulled into the next sprint. Some tickets might need to be archived(?), some can’t be worked on due to being ‘blocked’ in some manner (schedule, budget, discovery etc). Refining this list, and making this a reliable source for new tickets might help with finding tasks too.

@sid Agreed - I personally find the Bebop tasks list quite messy in general, both in the current sprint and the upcoming sprints / backlog. There has been some work recently to cleanup the active sprint, which had a bunch of tasks in the blocker column being bumped from sprint to sprint, and that improved things a bit. It could be worth looking at a similar cleanup for the backlog itself. Imho this type of things usually requires that someone stays on top of it, and proactively chase people. A bit like documentation often needs some kind of editor role to remain consistent. Anyone in Bebop would like to take that on? It could naturally go to the sprint planning manager, but I’m not sure it’s good to keep piling on too much responsibilities onto that role. We could have some kind of “Backlog editor” role, if that’s useful to separate it.

Also, I agree that tasks in the backlogs that could be moved to the stretch goals should probably be groomed to be moved there - it might always be harder for someone looking for tasks to take to get them from the backlog, vs knowing they are ready in stretch goals.

Task estimation

@ChrisChV

On the current sprint (in any state), with remaining time: These do NOT appear on Sprintcraft as Unestimated. I think these should also be reviewed and update the remaining time, since it may happen that many more hours or many fewer hours are needed, which can affect how we see our capacity for the next sprint.

Very good point. We would need to decide which tasks we would require to re-estimate though - is that all tasks in all states? Or maybe all tasks in the active sprint which are still incomplete? And that could be a ping from crafty on the second Wednesday evening - with Sprintcraft considering “unestimated” any incomplete task in the currently active sprint after that, unless its estimate has been updated after the second Wednesday?

Populating the last resort backlog

@Ali

I was wondering whether we could take a similar approach, but instead of having the funding upfront, aim to find a funder when/if a Product Proposal is accepted. The Client Owners and Sales Specialists in our team probably already have a good idea of what clients and prospects have asked for over the years, so what if we took that knowledge, came up with a possible solution, and created a Product Proposal to share with the community?

@Ali @Fox I would definitely love if we could do more proactive follow-up on client needs like this. There would probably need to be an assessment of the potential for a given product proposal to get funding from a client though - otherwise we would lose time, and make the community lose time too. Maybe a way would be, when a client has feedback like that but not the budget to handle it, whether they would be willing to partially fund it, if we found other backers? Having at least one party to commit some funds might help to weed out things that would be “nice to have” but never get funded, while also helping to find other backers, who would not need to do the first step alone, but would rather join an existing initiative.

@rafay

Below are the points that I have came up with after brainstorming session

@rafay Those are good interesting points - and actually some of those even already have budgets available, others would probably be good candidates for the last resort backlog. But to be clear, the problem isn’t per se that we can’t come up with useful tasks to do - it’s more that we need that additional work to be sustainable for OpenCraft, ie contain a reasonable amount of billable time. Otherwise, as we have seen in the past, we get a big inflation of internal unbilled work, which might be good and useful, but puts us in the red.

Off topic - Spillovers

Btw, with some of the reviews of the forum threads coming in too late this sprint, the tasks SE-6078, BB-8162 and FAL-3558 have all spilled over. To avoid this for similar tasks in the future, I’ll put an earlier deadline in the sprint for posting comments - but generally consider front-loading tasks that require back & forth in a sprint - it’s pretty much impossible to discuss something asynchronously when we start the discussion on the last day of the sprint.

Also, I notice that only one of the 3 tasks is in the spillover spreadsheet - am I missing something, or is something broken?