I agree with the creation of the last resort backlog, and that it should only be used in emergency cases. Not every time someone runs out of tasks, that’s what the Stretch Goals sprint is for. I think we should also think about how populate the Stretch Goals sprint.
I like the idea of yusuf, in the same way as searching for trial projects, epic owners (or another role) can search for tasks that can be added to the last resort backlog and stretch goals.
I remember we at Falcon have done this a few times before, and it has worked
I agree with review the estimations of all our tasks, in this context I believe that there are three types of tasks:
Not estimated: These appears on Sprintcraft as Unestimated. These are estimated before the day agreed in our sprint planning.
On the current sprint (in any state), out of remaining time: These appears on Sprintcraft as Unestimated. We need to update the remaining time.
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.
I agree with this I would add that on Friday w2: also review and update the remaining time of all the assigned tasks on our board.
A note here-- If I recall, one of the primary shortfalls that happened here in recent times was the fact that we had a client delay starting their project unexpectedly. There is always a chance that a client will suddenly pause or cancel their intended start for a project. This can even happen when we are notionally in control-- like when a discovery is almost finished and someone raises a question that throws planning through a loop. When that happens, we may not have sufficient warning.
This, then, is something I agree with.
No, we do not. We could certainly invest in prospecting this way.
I’ve managed to avoid this issue for quite some time because for a long time I’ve had a large epic that constantly generated tickets and work, and of late when I haven’t I’ve also had a lot of personal life interruptions that made it beneficial for me to take less work. I’ve simply tried to align my personal backlog of tasks with lesser OpenCraft work. This is obviously not sustainable.
I think the idea of a last resort backlog sounds good, but the bigger problem still needs to be addressed.
I think we can plan projects with larger buffers in mind. i.e. aim for completing projects at a slower pace to keep more room for ramping up i.e. keep a timeline buffer so that we can ramp up pace if low on work, but otherwise keep a slow pace while still reaching the client’s timelines.
+1 from me on the idea of maintaining a backlog of tasks.
I feel the most important aspect of this would be to carefully curate the tasks there frequently. Without proper curation, and removing of stale tasks from time to time, the backlog would become irrelevent pretty quickly.
I like the idea of @antoviaque doing this initially while we try it out, but we would need a system or dedicated role in place for this in the long term.
I think most of ticket in the current backlog were not put there with the intention of being picked up by anyone with a shortage of tasks. That backlog is mostly used to “dump” tickets which have no where else to go (mostly blocked before they could even start). That is the reason the current backlog tickets are so unhelpful for people looking for more tickets.
The last-resort queue is more purpose-driven, so I am hoping it would serve us better.
Shift deadline
+1 to this too. This might bring more clarity to our sprint planning process.
to this. I like the idea of a last resort backlog, but at the same time it’s quite stressful for me to jump into some new context only because I have to fill more hours. Especially given how usually diverse the work at OpenCraft (at least in Bebop). So it’d be nice to have this backlog and know that I won’t end up without work to do, but I’m in favor of what @kshitij suggests too.
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?
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 +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?
+1 - I have included this in the list of tasks above.
@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
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@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 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?
Usual workflow for me for estimating tasks for the next sprint is clicking on my name in SprintCraft and going through all the tickets there, especially where I am an assignee, and making sure the estimates are updated.
One of two - either it’s not working correctly for FAL project, or it’s ignoring subtasks.
I don’t see my unestimated tasks in the current sprint in SprintCraft. I have three unestimated tasks in the next sprint, but their scope can significantly change after some discussions with the client that I’ll have next week.
My impression from reading epic updates (which might not completely match what is actually happening) is that currently, not a lot of time is being spent planning ahead.
Epic updates usually tend to focus on reporting budget status (which is of course very important) and current work, i.e., tickets that are in the current sprint and/or scheduled for the following sprint.
Many epic descriptions don’t include Crafty directives for explicitly allocating time for epic management, or allocate only a small amount of time – less than the default allocation of 2h that SprintCraft assumes in the absence of Crafty directives.
Others might feel differently but in my experience, 2h or less per sprint is not enough time to complete the type of proactive planning activities that we’ve been discussing in this thread.
Even when it comes to current work, the level of detail that is posted varies quite a bit across epic updates. Some updates list both ongoing and upcoming tasks and provide relevant context on them, while others just have a under the Are all upcoming stories that we should work on in the next week or two created and in the correct upcoming sprint? header.
In hindsight, and in light of the current discussion, it seems like we didn’t necessarily do ourselves a favor by trying to simplify epic update templates as much as possible, because it opened the door to treating them as “just another checklist”. (Which is convenient when things get hectic at the end of a sprint, but makes it easy to forget that we shouldn’t treat epic-level planning as a second-class citizen.)
As part of epic planning management, we currently only check that epic updates are being posted at all. As long as they use the default structure suggested by the current set of templates, we leave it to epic owners to decide how much detail to provide. Follow-ups tend to focus on budget-related questions.
So what I was proposing above was for each epic owner to:
Adjust the amount of time blocked out for epic management so that it covers planning for future sprints.
Actively work on creating additional tickets each sprint – either for implementing existing/known scope ahead of time, or by coordinating with the client about additional work that the epic owner thinks would benefit the client.
Include details about available tickets in their epic updates, to allow other team members to find available tasks more easily.
… and for the epic planning manager to check that epic updates include this info.
Which overlaps with the items for epic owners that you listed above
–
These days my recurring responsibilities only leave a small amount of time for new tasks each sprint. Ever since taking up project management support for ASU my sprints have been quite busy, and now that I’m also filling in for Farhaan as epic planning manager for Bebop, they tend to be even more packed.
So I could take some of the items from the list of next steps in Sprint 314 but not all of them.
Maybe we could find a way to split the work between the two of us? I could take on task creation and scheduling, for example, which I might even be able to get started with towards the end of the current sprint.
+1 for a better way of maintaining the “regular” backlog, which is always messy and unclear as @sid mentioned.
+1 for a more clear process of finding work in the middle of the sprint, especially taking over tasks. We shouldn’t see a situation where one person doesn’t have enough work while other tasks spill over. If you look at recent sprints in the spillover log, you can see “Didn’t get started on this task.”, “Ran out of time to get to this ticket”, “This ticket had the least urgency, so I didn’t focus on it, to make sure that I completed the other tickets on time.”, “this ticket slipped my radar till it was too late”, etc.
I know not all tasks can be handed over, but I’m sure some of them can, and they should be. I know it’s also hard to admit to yourself that you’re not going to get to it; you think “oh, I’m behind but I’ll catch up and get that done” but then of course it doesn’t happen in the end. It’s easier to make the right call if you think “oh, someone else on the cell needs a ticket and I could help them out by giving them this”. Perhaps we can make more of an effort to call these out in mid-sprint updates?
I agree, but there is still a problem with this. Currently, the epic update is the main “reminder” that epic owners get for planning stories for the future sprint. But even if you do that on Friday, that’s too late according to Crafty and it will move your stories out of the sprint because they’re an “injection”.
I think you’re right about that. And as I mentioned above, there is no reminder to plan the stories that comes at the right time. Crafty reminds you on Wednesday but only says “do an epic update by Monday and split larger stories to small ones”.
What do you think about changing this reminder to say something like “Spend time today to create and review the stories for this epic that should be done next sprint, as well as any stretch goals. Make sure the stories are clearly defined, split large stories into smaller ones, ping potential assignees/reviewers, arrange for core contributor review, etc.” Maybe even add “Remember that epic management and reviews are higher priority than dev work.”
I think we should separate this planning reminder from the epic update, because as @tikr mentioned, the epic update has become very focused around budget and schedule, and you really have to wait until Friday to do the epic update anyways, because the time logs for the sprint won’t be ready by Wed W2. There could be a separate reminder for the epic update, or we may not need it at all, because it is covered by the Listaflow sprint checklist anyways.
@Ali I your idea is a good one. And I don’t know if we systematically track these issues. I’m not sure about the connection to the Last Resort Backlog topic but creating a place where Open edX bugs and requested features can be posted seems like a good idea. That way, we can track when there becomes a critical mass (minimum number) of requests for the same feature (or a single request from a significant client) that warrants the creation of a Product Proposal which could be submitted to the Core Product Working Group. Also a great way to contribute to the community.
Just a note, this is the kind of thing I would expect to be covered in Client Strategy Ticket work. Actually, it might be a good idea to create a checklist for this kind of thing in Listaflow-- there are several things we should be periodically checking in with the client about, but they can be easy to lose track of in the day-to-day. The client strategy ticket is pretty vague and may be too nebulous to be concretely useful still.
Has anyone successfully dug a new project out of the client strategy tickets yet? Or had any significant change/improvement from them?
I’ve tossed several tasks from Listaflow into the last resort proposed sprint since we’re (essentially) out of budget for the year but there’s plenty of planned work. Some of them currently have assignees, but I don’t think there’s any reason they need to be kept to those assignees if they’re needed by someone else first. Please let me know your thoughts and if I should move them out, @antoviaque .
Yep, we don’t really have budget for implementing new features right now, so it makes sense to continue using existing automations as much as possible. (I imagine that the amount of work required to change timing and content of the existing epic update reminder would be fairly small.)
In the medium term it might make sense to consolidate the different reminder/notification systems that we’re currently using into a single one. We have BB-8215 for adding support for item-specific reminders to Listaflow.
It’s currently a Last Resort ticket, so we might not get to it before the end of the year. However, we’ll be determining new budgets for non-billable work at the beginning of 2024 and once that’s done it should be possible to turn BB-8215 back into a regular ticket and schedule it for a sprint.
Once BB-8215 is done we can probably switch over to Listaflow for all recurring reminders that need to be sent out on a specific day of each sprint. (We’d still need to determine what to do for reminders that aren’t sent out regularly, such as reminders about updating due dates of epics.)
Thanks everyone for having estimated all the tasks! Sprintcraft still list some, but they look to be tasks that have exceeded their estimate, which is bound to happen during a sprint. It might make sense to differentiate those in sprintcraft.
(There are also some from @tecoholic@farhaan but they couldn’t see my pings during their vacation. @Agrendalath your tasks estimation seem fine to me too now yes for the current sprint - I don’t remember what the actual tickets were last time I checked - it could have been a task above its estimate.)
Improving epic updates
@tikr Looks like a great list of improvements, definitely on my side. To help with the adoption of these better practices, I would also add:
Change the format of the epic updates, to explicitly require more details & explanations. It could even include time/effort indication for each section (eg “List of tasks for next sprints (20+ minutes)”) or in the corresponding documentation, to make it clear that it’s not supposed to be a 5 minutes copy-paste activity, but a real effort to stop and think longer term.
Create a task in all the epic owners’ next sprint, to review the changes, and try to do the updates under the new guidelines. This would have the double effect of making the reviews more concrete, and to have done it at least once in the context of a dedicated task, before having to do it in a more “routine” way in the following sprints - to break the bad habits immediately, and deal with the extra complexity & mental load that changes require.
Last resort backlog
Thanks for the tasks! I’ve moved in a few tasks to the “Last resort - Accepted” list, both dev and UX-related so far. I’ve left a few in the “proposed” as there is already some buffer in the accepted list now; though if we did end up using them I could then easily pick some more from the proposed list. Hopefully we won’t need any of this! :p
Btw, I have created a “Last resort” board/backlog to show both of these lists, with tickets from all projects.
Applying the changes from the current discussion
@tikr OK, sounds good. Thank you for taking on this part! I could take on writing the handbook changes and creating the corresponding MR - I’ll create a task in my upcoming sprint.
This is actually something we tried to setup a few years ago - see https://www.youtube.com/watch?v=O6jhfUFL33M . It did get interest, but unfortunately no project got funding… We might have done it wrong though, or it was ahead of its time for Open edX. The (archived) result is at https://edxchange.opencraft.com/ - it was also tracking “upvotes” to gauge interest (but you can’t see that well in the archived version). CC @Ali
It could be a good opportunity to try again something like this. Let me know if you need anything to get this setup - time, budget, approvals (here or within Open edX). I care very much about this concept, so just ask.
I don’t have much to add outside of what’s already been discussed. I like the idea of having a “last-resort backlog” with the proposed monitoring. The only thing I would be wary about is this backlog not being populated when we don’t have enough billed tasks (either due to budget or general lack of work).
+1 for this. It would help to know definitively which order of priority to follow when there aren’t enough tasks.
The only other suggestion I have is perhaps creating a dedicated MM channel where people can post incase they don’t have enough tasks. It could take a while to hear back when you ping epic owners or task assignees for new tasks. This way we can track things better and it doesn’t get lost between other conversations.
I remember we at Falcon have done this a few times before, and it has worked
under the Are all upcoming stories that we should work on in the next week or two created and in the correct upcoming sprint? header.
Sprintcraft still list some, but they look to be tasks that have exceeded their estimate, which is bound to happen during a sprint. It might make sense to differentiate those in sprintcraft.