Tackling sprints without enough tasks

Discussions - Public
1

Background

There have been a few occurrences of sprints where work was lacking recently - it now seem much better than it was a few months ago, but that’s still seem to be an issue that pops its head from time to time. And I’ve recently discovered that @pooja ended up with very little work for several months recently - which is not a situation that’s acceptable. It’s part of OpenCraft’s responsibilities to ensure we all have work available, to match our current commitments.

This is a new type of problem, that has started around the beginning of the post-covid downturn, but also probably because of the measures we have put it place to avoid overloading the team, and the ones to keep sustainability under better check. With more capacity margin and less internal work, we need to be more accurate in our capacity planning, and also better handle the cases where we don’t plan properly, especially when there aren’t enough tasks in a sprint.

I’m suggesting two measures below, but I’m curious about other ideas.

“Last resort” backlog

To make sure cases like what happens to @pooja and others don’t happen again, I am suggesting creating a “Last resort” backlog, with a special budget. It would be populated by tasks that we would normally have not considered for a sprint, but that could be taken, as its name indicates, as a last resort when all other attempts to find enough tasks for a sprint would have failed. The idea is to not just let team members without enough tasks on their own in these cases, by providing both a last resort option, and a way to notice immediately when this happens.

Preconditions for usage

It is not meant to be a routine part of sprint planning - as its name indicates, it should only be considered after everything else would have failed. Including:

  • Pinging other cell members who have commitments in excess of their capacity, asking to split out/delegate some of their tasks
  • Reviewing one’s own epics for potential additional tasks, working ahead as much as reasonably possible
  • Pinging epic owners to ask for more tasks, either working ahead more, or splitting out/delegating tasks
  • For core contributors, matching your commitments, checking with other core contributors for work if you’re unsure what to work on
  • etc. (suggestions of items for this list welcomed!)

RCAs

Using the last resort backlog would mean that we failed to properly plan for our capacity, so each time it would be used, a RCA task would also be created and scheduled for the same sprint. It would be assigned to the epic planning manager, who is the best informed about capacity and best suited to address these issues proactively. It would also have as reviewers the sprint planning manager, as well as the people who had to take tasks in the last resort backlog, and myself.

Populating the backlog

We’ll also need to decide what goes in this backlog - it should probably only be tasks that are of the “important but not urgent” to us, to keep the tasks useful without having to change them every sprint. They should also be tasks that wouldn’t be done otherwise - for example things that are a few sprints out, or don’t have a budget. Many will likely be internal/non-billed tasks, but we should try to add billable tasks there whenever possible.

Do you know of tasks like this? Please add them to the “Last resort - Proposed” sprint that I have just created, I will review the tasks, and move some of them to the “Last resort - Accepted”, and assign a budget for them.

Initially, I would be the one deciding on tasks that would go in the last resort backlog, and their priority order. Tasks would be taken in order, ie always taking the ones at the top (eventually splitting it if that’s too big for the time remaining in the sprint).

Monitoring & planning improvements

Since this is only a last resort measure, we also need to improve how we monitor and plan for capacity in upcoming sprints.

Question for the sprint planning managers (@paulo @maxim @jill @ChrisChV @mtyaka @gabor) - do you currently check whether the upcoming sprint’s capacity and workload match? Are you even able to do that at all? The epic planning managers update & plan capacity vs availability via the epic planning spreadsheet, and sprint planning managers check that tasks scheduled for each sprint match budgets via SprintCraft, but I’m not sure that we reconcile this with the available capacity currently?

Looking at SprintCraft, it doesn’t look very straightforward to tell, for example for Bebop’s upcoming sprint. We are Thursday evening, so while we should have all the tickets for the upcoming sprint created already, we don’t yet have all the estimates. I currently see for Bebop: 492h assigned, with a goal of 688h, thus a current gap of 196h. This gap might be filled once the remaining unestimated tasks are estimated, but this might only be something we can see on Monday? Which might be too late to do something - so should we do estimates earlier, by Thursday evening like for task creation?

Side remark about task estimates - some are completely missing!

While looking at this, I notice that there are many tasks in the current sprint that aren’t estimated, which should not be possible. If some of the tasks in a sprint are not estimated before it starts, I’m not sure how their owners know whether they are not taking too much or too little work for a given sprint? @artur @demid @kshitij @Cef you seem to have quite a bunch of unestimated tasks - could you comment, and fix this in upcoming sprints?

[ Ticket to log time ]

7 Likes
2

FYI, I have created a task about this and Firefighting issues - Coverage, escalation & backups in everyone’s upcoming sprint (with a couple of exceptions), to have proper dedicated time to think about this and respond.

1 Like
3

@antoviaque, usually I try to go through all not estimated tickets on the board in SprintCraft, but yes, it’s my fault that sometimes I may neglect that if I have only few small tickets or mostly one large ticket to do (which is the case this sprint). I’ll fix this in upcoming sprints.

1 Like
4

@antoviaque It completely escaped my mind and I apologize. I will fix this in the future.

1 Like
5

I haven’t been doing that. Since Serenity is just Gabor and myself (and I am only part-time) I found that a lot of sprint management duties aren’t really useful for our cell where we each organize and prioritize our own tickets.

6

As Matjaz said. – same for me.

7

I like the idea of the “Last resort” backlog. It ties in with the idea of “working ahead” that we’ve been discussing on the this thread. There is so much UX work to do (especially for Libraries V2).

Here are a few of the projects I’ll be adding to the “Last resort - Proposed” sprint:

  • Exploratory wireframes for Content Libraries V2 (Create any part of the course in Libraries for reuse)
  • Copy / Paste Custom Pages (Design already complete)
  • Studio Sidebar Updates (Would need to liaise with 2U to see if this fits in with their plans for Studio)
  • Listaflow Reports
1 Like
8

Ditto @Ali. I think this does tie in nicely :slight_smile:

Here are a few of the projects I can add to the “Last resort - Proposed” sprint:

  • Wireframing the proposed Gradable Discussions MVP before sign off from ASU and the community. Although we could probably get this moving fast in the coming weeks.
  • Wireframing the areas of the HMX Custom Pathways that are most crucial to getting this functionality up and running.

And then we have some internal projects we could look at again if needed. We’d just need to discuss how best to tackle them:

@antoviaque You may have mentioned this somewhere, but when creating the “Last resort” Jira issues, should the “Last resort” sprint be available in the following dropdown:
Screenshot 2023-11-15 at 13.15.37
Or how should we go about creating the issues?

2 Likes
9

@cassie It should be possible to add any task to that sprint, I would assume - though it’s possible that it’s still missing some Jira-fu to make it happen. On which task were you attempting this? I’ll have a look.

1 Like
10

@antoviaque I haven’t created any issues yet. But if I try to create one and search for “Last resort - Proposed” nothing comes up in the dropdown. I’m not sure if this is the correct way we should be doing this though?

11

The dropdown only prepopulates sprints that Jira thinks are relevant. If you start to type ‘Last’, the autocomplete should repopulate and offer it, I’d think.

1 Like
12

That makes a lot of sense. I’m seeing a see-saw movement in work available: sometimes we end up with spare capacity, and other times we have tickets going to Stretch Goals because there’s not enough capacity to tackle everything in a single sprint. This would help alleviate the lack of work when we have spare capacity.

Usually, Stretch Goals and the future-sprint fishing should be able to remedy this, but it seems we are not able to generate enough billable work to keep these populated. At least for MoE, I’m pulling tickets from future sprints when I don’t see enough work available, but the epic isn’t able to provide enough work on every sprint.

One idea is creating tickets for Grove-related issues that Serenity isn’t able to work on.

On some sprints, it’s quite hard to understand the real situation due to unestimated tickets. I add guesstimates to unassigned tickets and try to get them assigned. For tickets already being worked on, it’s more complicated: I cannot say how many hours that ticket will require in the next sprint; and with this affecting one’s capacity, it also makes it hard to understand our real cell capacity. It also makes it hard to find out if people holding unestimated tickets are under/overcommited.

It’s quite difficult to change this schedule. We aren’t always able to get tickets scheduled early as we depend on clients for that. Having a ticket creation deadline and estimation on the same day might cause not all tickets to be estimated by everyone due to time zones. When I start working many are already close to their EOD.

13

@cassie Yup, my assumption is that it would work like Fox said. If it doesn’t work for you, try to create one ticket without assigning a sprint to it, and ping me on it, we’ll try to sort this out.

1 Like
14

A Last Resort backlog (with its attendant safeguards) sounds like a good idea.

Would this also be a source of trial projects for recruitment, if all else fails?

If people run out of work during a sprint, we also suggest:

  • Ping assignees on “not started” tasks to see if you can take it over.
  • For tasks where you’re a reviewer, ping assignee to offer help.

But I don’t think this list is in our handbook anywhere? It really should be; this comes up often.

No, I don’t check this as part of sprint planning; I only check that people are not over-committed.

:+1: I think that’s worthwhile.

Could part of accepting a pre-assigned task be setting the hours estimate? That’s also a good time for the assignee to split the task into smaller pieces or timebox if possible.

Would a lighter-weight, Kanban-style sprint work better for Serenity? You’d still need to maintain a dev backlog, but the “sprint” could be more flexible in case of operational issues.

1 Like
15

Just a note here-- if there are sprint planning tasks in particular that you have in Listaflow that don’t need to be there, let me know. The tasks are generated based on tags/roles, and we could change how they apply to Serenity team members. My sprint checklist only has 11 tasks, whereas Bebop cell members typically have many more, for instance.

Oooh. That is a good idea. But this begs the question: How do we ensure this list continues to be populated?

One of the reasons we’ve had such difficulty with finding trial projects and keeping a backlog of them is because these kinds of tickets aren’t often created until we get serious about doing them. Making sure they’re visible is only half the problem. We need some kind of prompt and time for looking through our projects and creating the relevant backlog entries. The ticket we have in our current sprint might work for populating the first few entries, but how do we make sure these keep getting made?

Possible solution: @antoviaque monitors the sprint, since it’s his to guard, and if he feels it’s insufficiently filled, creates tickets for team members to spend time coming up with ideas?

To note, basically everything in Listaflow’s roadmap could go in this sprint. Day-to-day, the project works fine, and we keep making progress with our current budget. But there’s always stuff that could be done with it that is in that ‘important but not urgent’ category. Even more if we had another UX design ticket or two done ahead of time such that the tasks just need dev work.

This would be a lovely addition to the handbook, yes. I think we’ve occasionally kicked around adding some kind of guide on ‘how to find work’ to the onboarding course. However, since it can be months between ‘totally full’ and ‘need more work now’ it’d probably be good to have it in the handbook generally.

Anyhow, it’s been one of those ‘important but not urgent’ things, since by the time the idea comes up, it it’s usually resolved. :slight_smile:

1 Like
16

I see you wrote that these tasks may won’t be billable. Is this means that Serenity tasks counts as well? If yes, I’m happy to throw some tasks in that backlog.

I know it is OpenCraft’s responsibility to provide enough tasks & the assignee’s responsibility to take enough tasks (so it is a two way street), but it will definitely affect the sustainability – which is unavoidable I guess. Though, how could we mitigate that? I mean, if we build up worst sustainability I’m afraid that Serenity won’t be able to “outsource” tasks to Bebop or Falcon. If that’s not a concern for others its not one for me either.

As mentioned above, we did not do it with Matjaz as Serenity is two of us, and the Sprint Planning Manager role suits for 4+ members as I experienced it. However, @mtyaka may have better insights on the number “minimum members” where the role worth its existence in the form it is right now.

@Fox I believe that would be a relief, though we would need to figure out what tasks are not applying. What do you think @mtyaka?

I may remember wrongly, but shouldn’t that (estimating) be done by the assignee? Also, the sprint roulette should help the situation of unestimated tasks. Isn’t it working out? I’m asking as I remember we tend to forget about it.

@jill Does it happen often? Falcon could try reaching out to Serenity as well as we may can provide some tasks too – as we do for Bebop occasionally.

17

I was referring to the remaining hours in the ticket. Tickets without story points only happen when a ticket is injected after the estimation session is closed.

I try to guess the remaining time to get tickets assigned before the end of the sprint. Since I’m working on the latest timezone, I do a final round of planning an hour or two before the end of the sprint, assigning people based on the SprintCraft report of hours available.

2 Likes
18

It would be a great thing if we could do it, but I never understood how.

The link is wrong, because I accidentally created a copy of the board (you probably saw Bebop listed twice in the sprint craft; we deleted the duplicate quite quickly, so I didn’t think anyone would be affected). The id (at the end of url) should be 26.

I remember this used to be a debated topic, i.e. whether we should shift the dates on which we start planning, about a year and half ago. In practice, most of the sprint planning is done on Friday and Monday, including the estimates. I can admit that most of the time I set the estimates for my tickets early on Monday, and spend the rest of the day either looking for more tickets or reassigning them, if I’m overcommitted. I have similar feelings to what Paulo is saying:

I believe we try to do our best. Too often we have to play by ear, which requires us to ignore the sprint schedule.

I wonder if there is something we can do to encourage doing it earlier in the sprint, i.e. that most of the planning, ticket assigning and estimation is done on or before Thursday week two, and Friday and Monday are left for adjustments.

Should we temporarily try to shift the deadlines by one day earlier? E.g.

  • Wednesday W2 - deadline for creating tickets
  • Thursday W2 - estimation session
  • Friday W2 - closing the estimation session; on Friday everyone would be expected to estimate the tickets and already have a plan for the sprint
  • Monday W3 - final adjustments, i.e. Sprint Planning Manager checks the numbers; people who don’t have enough work can look for tickets; people who are overcommitted reassign tickets

I think, if the effort to give it a try for couple of sprints or even months is <10 hours, we should give it a try as an experiment. We should set a date on which we evaluate the results by comparing them to the current state based on some metrics (I don’t know what metrics, at the very least we could ask cells and people with certain roles some questions, check the stats like hours). If it doesn’t work, we can revert it. I think, we should take advantage of the fact that we are small company, and do small experiments like that more often.

3 Likes
19

Generating & finding tasks

@paulo It could be worth digging a bit into this. I wonder if it’s something that we really can’t do more than we do now, or is it that it would require to dedicate more time and effort to figure out those future tasks? It’s definitely something hard to come up with quickly, when pressed on by other duties, it usually requires careful planning, as well as educating clients and following up with them ahead of time to be able to plan further ahead. Would it help to get dedicated tasks assigned to some of the epic owners, when we see that upcoming sprints are going to be missing tasks?

@Fox +1 about having proper tasks to generate tickets, and to do it “just in time”, only when we think we will actually need it. Note that before checking that there are enough tasks in the last resort backlog, we first need to detect that such a gap is likely to occur. If not, it’s not worth spending time preparing tasks ahead - the time is better spent working on the current work.

Also, checking on whether a given cell is going to have a gap or not needs to be done at the cell level, by the people the closest to the work. It would be difficult and likely counter-productive to centralize this at the company level. Same thing for creating and assigning the tasks to epic owners, for creating more tasks - imho these duties fit best the roles of epic and/or sprint planning managers.

On my side, I could review the tasks put in the last resort backlog, and also be an escalation step in cases where not enough tasks are found. I can also put some tasks in that backlog when I notice something worth putting in there.

+1! :+1:

Detecting capacity issues & estimation

@paulo Yup, I can imagine - that’s what I was seeing when I tried to get a feel for how much capacity is needed for the following sprint, it’s hard to tell when most tickets are still unestimated. And it’s a good point that the tickets in the current sprint make that even harder. Maybe when tasks are estimated for the next sprint, we should also review the estimations of the tickets in the current sprint that aren’t done?

I also don’t think sprintcraft currently considers the time left in the current sprint when estimating capacity for the following sprint? Ie, in ongoing tickets, we should probably not consider that all the time will spillover in the following sprint, only the time left on tickets that exceeds the remaining hours in the sprint?

Btw I still see a bunch of tickets in the current sprint which are unestimated - if you have one of those tickets, could you go estimate those now please?

It’s true that it’s difficult, few are the clients who plan much ahead. But it’s also our role to help organize work, and to defend what we need to be able to work well - and asking for work to be properly defined 2-3 days before we have to work on it isn’t an outrageous ask. It’s also in their interest to allocate our time well - that is important to keep an acceptable overhead on our side, which otherwise we end up having to pass on to them.

@paulo True, we always depend on the “last” timezone to prepare everything correctly - that said, even if the estimations are only finalized late into the night on Thursday evening, it’s still better to be able to have an extra day on Friday to check on capacity vs backlogm vs only being able to see it on Monday, when people on early timezones would already have finalized their next sprint?

@maxim +1 from me to give it a try :+1: Experimentation is a great way to do reality checks, and to make discussions more fruitful through concrete experience.

Sustainability

That is indeed a very important point - the existence of a “last resort” backlog isn’t a solution to the lack of tasks, it’s only a measure to avoid putting the weight on the shoulders of individual team members who end up short of work. But, to reiterate it clearly - the last resort backlog is a backlog that we can’t afford to use!

We have managed to do without it for 10 years and had (a lot of!) work for everyone, with good sustainability - that’s what we need to go back to, and find solutions for. If we don’t and end up using that backlog regularly, sustainability will keep being bad, and eventually we’ll all be without a job. Ie the last resort backlog a way to mutualize the risk associated with not having enough billed hours, but it doesn’t make it disappear.

Serenity-related topics

Yup, anything that is useful to the team or project can potentially be considered for inclusion there. Note that I might not accept everything there either, it will depend on how impactful the change is, its priority, and its potential to eventually bring us more work. But in terms of type of tasks or cell origin, we can consider everything, especially now as we are figuring things out.

We have been discussing doing a bit of this recently with @mtyaka and @gabor, and we can do some of that, but it has to be bounded - otherwise we will fall back into the issue of having an infinite pile of unbilled time being accumulated on DevOps tasks. The size of the Serenity cell is what serves as a budget cap, ensuring we prioritize tasks to fit within the budget we can afford for them. That said, when Serenity does billed work like currently for the Axim sandboxes, that gives the cell some budget to delegate tasks to other cells, which is what is being done currently.

@mtyaka @gabor Yup, I can imagine that some things become simpler when it’s only two people :) It could be worth going through the list then, to see what is useful and what isn’t. It’s also important to keep some of the discipline that the sprint and epic planning workflows bring - for example in terms of prioritization, ensuring that you are not overloaded, matching deadlines. Generally, it wouldn’t be good to have you two too cut off from the needs and practices of the other cells - we are still one team. It’s important for you too btw, since that integration is what allows to balance your sprints.

It would be worth taking on @Fox 's offer to refine the sprint planning checklist for your cell - could one of you take on a task for this, with the other as a reviewer, as well as @Fox for the Listaflow side, and me for the consistency bit?

Trial project tasks

@jill Potentially for some tasks, though the needs are a bit different - on one side the goal is to properly assess the full range of skills of someone in a short amount of time, while on the other side the goal is to find work for someone who is already in the team. So my expectation would be that it would only be a small subset of the last resort backlog that would be fit for trial projects - but it could still be worth checking it when we really can’t find a trial project task, just in case. The priority would still be for the existing team members on these tasks, though.

20

I think this is a great idea. Most of the planning is done on Friday/Monday, if one realizes that he is short on tickets on Monday, pinging people then won’t guarantee a response due to availability and time zones. The earlier the final adjustments are initiated, the better the chance to succeed in starting a well-planned sprint