Creating Forward tickets more regularly

Ticket to log time

Hi @team !

I’ve noticed a few times where our processes are stymied by a sudden need for an influx of tickets but an insufficient backlog of them. One of these is the recruitment process, where locating a trial project becomes difficult, and another is the case when a client has to pause work and team members suddenly need to find other tickets to work on.

While at the moment there is also some need to pull in additional clients (something we’re certainly working on!) there does seem to be a consistent difficulty in creation and assignment of these ‘buffer tickets’. I’m curious if we can determine why that is and change something.

There are a few thoughts I have to the cause:

  1. It could be that creating longer ticket backlogs is not something we’re excited for or incentivized to do, so we focus only on creating the tickets we need most immediately every time we do epic management.
  2. It could be that these tickets ARE created, but that since we assign team members upon ticket creation to make sure they don’t get lost, it’s not obvious which might be reassigned in the case that the ticket is ahead a few sprints and the assignee is able to relinquish them without risking their own billable hours.
  3. It could be that uncertainty in the project’s future priorities makes epic owners unwilling to create tickets that may perform work that must be respecced later.
  4. It could be that budgets are a primary concern-- if we’re suddenly adding a 20-40 hour ticket to a client’s project, and the client is already maxing out hours, it’s not clear how we can handle billing for these cases, and a sudden monthly increase if communication/invoicing isn’t handled properly here could result in some client relations issues.

What are your thoughts? Do any of these ring true for you? Are there any changes we can make to better incentivize creating larger backlogs for buffer?


(I don’t want to bias the discussion too heavily so I recommend you note down your own thoughts before you read mine below)

Expand this to see my response

First, if you look at the Bebop + Serenity backlogs there are actually 124+118 = 242 tickets in the backlog. Before we go ahead and start creating new ones, we need to do a better job of clarifying, updating, and deleting the backlog we already have. There is a danger of creating tickets too liberally, which is that you end up with a huge backlog of low-priority or outdated tasks, and it becomes a source of noise and meta-work for people to sift through and find suitable tasks.

I actually like to have several backlogs, like “Ideas”, “Low priority - needs refinement”, “High priority - needs refinement”, and “Next up” so that you can have a huge backlog without burdening people with that meta-work of sorting through it all the time. Do people think something like that would be helpful for our team?

Second, the nature of our work is largely client-driven and for many of our contracts, that means we have to work in a way that’s fairly responsive to the client’s current needs and budget. We can’t just create a huge backlog and then work through it - it may no longer reflect the client’s priorities or budget by the time we get to that ticket. Projects that’s we “own” like Listaflow and Open edX Theme are much easier, because we do the product planning, the output of that is the backlog of dev tasks, and we manage the budget. But even when there is a large project with a well-defined goal, whether it’s a client project or our own, it’s simply not a good idea to try to spec out and then implement all the tickets from beginning to end - as we know, an agile approach is much more effective.

I think that’s a big part of it. Sometimes I have gone through old tickets or under-specified future ones and pinged people about them, and then they’re good about cleaning it up, but without someone asking that it often doesn’t happen. This is actually something that anyone can do - you don’t have to have any context on the epic in question (perhaps it’s better not to) to review tickets and ask the reporter/epic owner if they need to be improved. Maybe we could assign that to someone in each cell?

What’s more, we know that in general people often don’t get/take enough time for epic management, and it’s often a focus at the end of the sprint to finish dev tasks, so any type of epic management gets rushed.

Yeah. Also, I think that if people also assume that they’ll be taking the ticket themselves, it feels like there’s little advantage in detailing it in advance if they have the info in their head. But of course, it is still useful to write it down, to help think through it and in case you don’t take it on, so people shouldn’t do that :p


@Fox Thank you for creating this post. As a recruitment manager, it has always been a challenge to find the Trial Projects. The one time we were able to do it with a client facing ticket, it required merging a couple of smaller tickets and delaying it by a sprint or two. The other times we have fallen back to using internal projects.

Since I have not been a client owner, I haven’t been able to experience the issues myself, but the other client owners have always mentioned “lack of client budget” or “limitation of client budget” as the main reason. I specifically remember ESME doing a discovery for a good OSPR ticket, but not implementing it due to budget constraints. I think a big percentage of epics/clients are on “maintenance mode”. The only project in recent memory in “active development” mode was the “Skills Tagging” project. Even that I think is now coming to an end.

Some hope…

I have become the Epic Owner HMX Pathways project recently, and we have been in a slow discovery phase for a while. But we are getting into active development phase this year and I am hoping this will be a good “scoped project” with a lot of possibilities. And that would make it possible for us to create a decent amount of buffered tickets.

1 Like

Thanks for starting this conversation @Fox :rocket:

It’s very timely – as mentioned in the latest sustainability review, Bebop will need to find a way to increase throughput of billable hours in the coming weeks and months to further improve the cell’s (and by extension also the company’s) sustainability ratio.

This will require that more tickets be created and scheduled on average than is currently the case for client epics, so it’s a third scenario where proactive ticket creation plays a crucial role.

Expand this to see additional text quoted from Braden's post

On this aspect in particular, an idea that’s been lingering in the back of my mind for a while is that we could try decoupling the ticket creation part of epic management from the end of the sprint, and schedule it for the first or second day of the new sprint instead.

That way:

  • Epic management at the end of the sprint would be mostly about double-checking the scope for the upcoming sprint and making some adjustments based on last-minute changes requested by clients.
  • Planning for future sprints and ticket creation could be done more calmly, and epic owners might be able to clarify / update / delete tickets in the backlog more regularly.

Expand this to see text quoted from Braden's post

If people feel that this is needed, it might make sense to add it to the scope of an existing role, e.g. sprint planning manager. I’m not in favor of creating a separate role for it, considering how hard we’ve fought to bring down the number of roles and responsibilities that cell members need to handle :slight_smile:

Expand this to see additional text quoted from Braden's post

Development projects with well-defined scope (like Skills Tagging) might be an exception here. At least to the extent that work on individual deliverables is parallelizable, it should be possible to increase the amount of work that is scheduled for individual sprints by spending a bit more time on planning and creating more tickets in advance?


My guess is that these are the two biggest reasons why creating tickets in advance is problematic. I’m curious to hear others’ replies, but I think if it was just “1. I don’t enjoy/don’t make time to specify tickets”, or “2. There are tickets, they just need to be reassigned”, then in a pinch, like when there’s a newcomer knocking on our door, we could find the tasks we need. But it never seems to me like there’s work waiting in the wings for this purpose.

And the combination of these two is pretty brutal, from a planning perspective. If the client’s goals are constantly shifting, then it’s hard to see where they’re going, and impossible to anticipate what feature or enhancement or operational change might benefit them the most. Mix in a minimal budget, and there’s now no time to even speculate and meet and discuss what the client’s goals may be, and rarely any budget remaining to achieve them, either. You’re always playing catch-up, and everything is decided/spec’ed/planned at the last minute.

As engineers, we sometimes see these limitations as fixed constraints, things we can’t do anything about, and so just have to operate within. But we can relieve this tension by setting aside a minimal amount of time (1-2h) to a) start the discussion with the client about their larger goals (hopefully beginning with a value proposition so the merits of our collaboration are fresh in their minds), and b) ask whether there is any more funding available to achieve these goals. Maybe the answer right now is “no”, but we can keep asking, and hopefully they find something important enough to fund a discovery and a mini-project. It can also help tame the constant shifting of priorities, so that everyone feels better about the value we’re providing.

The sweet spot (for me) with epic management is when I’ve just finished a small discovery – coincidentally, like the one I finished last sprint. I got to spend part of the discovery time creating and specifying tickets, and scheduling them across the next few sprints. It makes my epic updates look like a project plan, and the updates for my next few sprints will be really trivial, just some shifting around if things don’t get done according to the expected timeline, or adding things in if new stuff comes up.

So, the sweet spot I described above is glorious, but for several reasons, it’s rare for a Discovery to lead to a good Trial Project. And this, I think, is the real issue here.

  1. Most of our Discoveries are done for prospective clients which we’re bidding for.
    Timing landing this client with landing the newcomer who will work on it is hard.
  2. Discoveries for existing clients don’t usually contain time for onboarding.
    Maybe they should, but when we’re trying to sell a tidy block of work to fit within a minimal budget, it’s hard to add padding for new people.
  3. My last discovery was needed because the work proposed is complex and intricate, and so an implementation plan is required in order to avoid making a total mess, even though I have lots of context.
    Newcomers don’t have that context, and would struggle to follow my plan, no matter how well laid out.
OK, reading and replying to @braden 's and @tikr 's posts now:

Yes! That has helped heaps with LX on their task board. And note – these backlogs still need tending, and that requires communication with the client about more than just what’s happening next sprint. Before “Next up” empties out, we need to be working with them to refine the tickets for the next milestone. So it doesn’t have to be all the time, but it needs to be regular.

And if we tag the tickets in the wings as potential Trial Projects, this could help.

Absolutely, and a huge backlog is a waste of everyone’s time.

It’s a nice idea, but I doubt that ticket creation will get done if there’s no immediate requirement to do it.

That and, without knowing the client’s upcoming milestones, how do we know what tickets to create? I still think the problem is farther up the planning chain.


@jill I agree that in order to solve the original problem, we should take into account issues at all levels of the planning chain :+1: Thanks for providing your perspective on those.

I probably should have emphasized it more, but I wasn’t just talking about ticket creation above:

In my mind, this involves a lot of the steps that you mentioned:

  • Client management:
  • Creating project plans for specific deliverables/milestones belonging to existing epics (which may or may not be based on additional ad-hoc discovery):

It will be interesting to get the perspective of other epic owners on this as well, but my impression is that these things are much less likely to get done when people are in a time crunch at the end of the sprint, and avoiding spillover becomes the main priority?

1 Like

@team There are a lot of great ideas here and the discussion is getting involved, so I’ve created tickets in all the developer cells for each team member to review/comment in depth next sprint.