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:
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.
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.
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.
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)
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.
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
–
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.
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.
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.
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 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?
@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.
I think we have an automation that is supposed to be scheduling tickets to block out time for activities like this. I’m actually not sure where the automation is currently hosted-- but I haven’t circled back in a while to see if it’s still working. I believe @maxim made it a while back-- epic owners were supposed to get quarterly tickets to think on strategic opportunities for clients, which could include contacting them to ask about plans like this. Our infrastructure has changed a lot since then and it may have broken, though.
Has anyone seen these tickets in a while? Are they still being made? Until now, I’d completely forgotten about them!
AFAIK, it does work, though may be there are corner cases where it doesn’t work.
If you add a client-epic label to an epic and the epic has status In Development, the scheduler will create tickets.
Out of all the epics which have the label, the scheduler hasn’t been scheduling the tickets for BB-6092 because it has status Backlog and BB-5744 because it has status Recurring. We can change this behavior, if it’s needed.
I also see that it didn’t schedule a new ticket for BB-334, and I’m not totally sure why. If we have the budget, it would be nice to schedule a ticket to investigate.
I did a bit of digging, and apparently BB-6746 is not considered finished, probably because it was Archived instead of Done. It’s weird that’s behaves like that, because the scheduler checks whether a ticket has resolved status, which archiving the ticket should do. I’ve moved the ticket Done, and now it’s considered done, so a new ticket will be scheduled eventually.
I’m certain we have the budget to afford a handful of non-billable hours to help us schedule scores more billable. :) Could you go ahead and schedule such a ticket? You should be able to put it under the Automation account, or sales management. cc @tikr@gabriel
The plan is to change the scheduler to also schedule tickets for the Recurring epics and change the implementation to more reliably recognize the completion status of the tickets.
Expand this to see additional text quoted from Braden's post
I think creating new backlogs for that would cascade really quickly and we won’t be able to properly manage 3 * 4 backlogs (Serenity, Bebop, Falcon - backlog, “low prio”, “high-prio”, “next up”). Also, it destroys the idea of a backlog. However, the idea is great! Categorizing the tasks we have would be awesome. How about the following?
Create new label: “needs refinement”
Use the priority field properly (ie. set the priority)
Regularly clean up abandoned tasks that are older than 1 year. 1y+ tasks probably will never be done (except the tech dept we have at Serenity backlog)
If we do this, we could create a simple issue backlog filter for “newcomer friendly tasks” or tasks that still need to be refined.
Anyways, I’m not against the several backlogs either after all, just trying to avoid a too fragmented backlog.
+1
Probably. I do like planning, but sometimes I’m struggling with this too when I know I should have create ~25 tasks for the next 2 sprints. Though it is a bit different in Serenity.
I feel the reason is a bit two-folded. On one hand we don’t really have much project-like/project-size tasks that newcomers could work on. On the other hand, even if we have, we may not promote it as it must be done quickly and we have not much time to restart the implementation if the newcomer did not succeed. For example, I feel that was the case for many parts of the Library v2 epic. There were tasks that could have been scoped properly, but the complexity and time pressure did not allow us to cut trial projects out from that epic. (or am I on a wrong track with that @farhaan ?)
Also, Serenity would have sooooooo much trial projects, though we cannot really promote any, because the newcomer would need too much permissions and access to the systems we may not want to give. Also, that wouldn’t help with sustainability either.
That would be a great idea! I’m trying to force myself to that too, sometimes it works.
@Fox We’ve fixed the small issues that were found as part of BB-7108 and I’ve also added Falcon and Serenity to the projects the scheduler will check, so this can be used by other cells as well. cc. @jill
From what I’ve seen, the two main reasons for a lack of tickets being created in advance are usually:
Client budget: A large number of epics are plagued by budget constraints. A lot of times, we’ve had clients agree for discoveries for features or changes that we think would benefit them, only to shut it down when they see the estimates or the timeline required. And we don’t have much control or view into their planning so we can’t really anticipate when they would be ready to pursue it again. Especially with limited budget, clients would rather have us focus on the immediate requirements they might have or solve issues that might arise instead of bigger tasks.
Sustainability: This is more relevant for Trial projects for newcomers. For client projects, I agree with @jill 's points about the challenges around timing it with when the newcomer would be starting, minimal budget and lack of context. There’s also the risk of the work not being done on time if the newcomer fails their trial, or exceed the budget approved if they take longer, which would have a negative affect on our relationship with the client. We’ve got plenty of work on our internal projects, which would be ideal to be used for Trial projects since it allows us to judge the newcomer’s capabilities without risking the timeline or budget issues for clients. We also have more control on planning for our projects, so it would be easier to account for uncertainties. But we can’t use them due to sustainability. Perhaps we can stick to using internal projects for Trial projects, but restrict the hiring to only when sustainability ratio is better?
I’ve done this too. Perhaps one of the completion criteria for discoveries could be to at least create the tickets, incase the discovery is accepted?
Expand to see text quoted from Braden's post
That reminds me more of trello boards. But we’ll need one for each epic, to better categorize them. Otherwise it could get a bit messy.
Could you document this change in the handbook, e.g. in the Epic Management: epic template? If it’s already documented somewhere else, then even a link there would help make this feature more discoverable when people are creating new epics.
I wonder… if we’ve got a completed discovery that the client rejected due to budget constraints, could we offer to assign the work to a newcomer split the cost with the client? If we’re clear up front about what we’re promising, then we could balance the risks for everyone, e.g.
The client knows this is being done by a candidate, and so accepts that it may take longer than originally expected, and may require more back-and-forth to get the features right.
We could quote a fixed cost to the client but just a tentative timeline, so their risk is time/quality, not cost.
If the newcomer doesn’t end up completing the task, then OpenCraft bears the sustainability burden of finishing the work when our capacity allows.
The risk to our sustainability isn’t as high as it would be for a fully internal project.
Scope changes would need to be individually negotiated – newcomers will need a lot of help from their mentors/task reviewers to identify and manage these, since they’re under pressure to please all sides. But even that would also give us insight into the newcomer’s ability to manage shifting requirements and communication, all of which are good things to see during a trial.
@jill If this isn’t likely to scare off the client, why not yes
Also, for trial projects, remember that if nothing is available a fallback is to take a ticket from the Open edX project and get the candidate to contribute it upstream. It takes more unbilled time than a client project, but with recruitment speed is important - the more time between the moment a candidate applies and the actual hiring, the more likely they will have found something else (which we have seen apply to recent candidates btw). Also, contributing a task upstream used to be our main recruitment test, and it worked quite well.
I would like that It’d be great to have a place to dump ideas without having to fully spec them out.
That could be useful at times when we’re actively looking for tickets, but I don’t feel it’s worth making this a regular task. I’d leave it up to the epic owner oh how clean they want to keep their backlog of tickets.
Other than the reasons others have already mentioned, one of the problems is that tickets where priority and budget align perfectly for a trial project are very rare. Tickets for which we have budget are usually high enough priority that we can’t just keep them in the backlog for many sprints. It’s a bit better with internal projects, but I think this problem happens with internal projects as well.
There are some amazing ideas here and the problems that I am going to be pointing out about creating forward tickets could be just related to specific epic.
The Epic that I own has a severe budget restriction, so scheduling forward tickets is not something that I have the luxury for, at least for now. Having said that, we did get some budget to reduce the code drift, which can be a good candidate to try creating forward tickets for.
Having said that, with ongoing projects, there are times when you don’t really have much development work going. Under such Epics, creating Trial Projects/Forward tickets is not possible.
At times projects are time critical, and it can be unhealthy for the project to on-board a newcomer, I often have this dilemma that I shouldn’t be spending client’s time/money for our benefit. When I think through this, I do land on the premise that it could be because that tasks are not well detailed, or the discovery wasn’t able to do justice to the Epic Plan. Hence, it becomes a bit more difficult to give a task which has uncertainties to the newcomer.
I think most of what I have to say about this is pretty-much already covered by everyone else, but I decided to go through my own history of epic to analyse the situation with those.
For Yonkers, either we had project where all possible tickets were created in advance, or general support tickets, which were created when an issue was brought up, and scheduled when we were told to do so.
I think this has been a major reason for me. For many projects I’ve seen that creating tickets too early isn’t very helpful. Not all tasks are workable at all times, and sometimes the definition of a future task depends on work that’s yet to be done.
I’m not entirely convinced of budget as a reason, since that prevents scheduling tickets, not creating them, although creation also takes time.
I think for such tickets it would generally be OK to ping the assignee, and reassign, I’ve seen this happen a number of times, but it’s certainly an extra step.
I agree! I think aligning a trial project with a ready nice bundle of related tickets that a newcomer can take is going to be hard at best.
I’ve generally not coupled ticket creation with the end of the sprint, I’ve always thought of it as a deadline, so I try to create the tickets before that, whatever that day may be.
Thanks for providing your perspective on those.