Something in the Core Product Meeting yesterday got me thinking about another way we could populate the Last Resort Backlog…
Recently, EduNext has been collecting feedback from their clients about the things they do and don’t like about how their Open edX instances work. The type of feedback they have received varies, from requests for new features, to complaints about how existing features work. EduNext has taken this feedback and started to create Product Proposals outlining possible solutions. They share the proposals with the Core Product Working Group for input and approval (here is a board displaying the current proposals). I think the majority of EduNext’s proposals are funded by the Spanish Consortium.
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?
I’m not sure if this is a good idea or not, but I thought it couldn’t hurt to mention!
@Fox@DouglasDraper Do we keep track of requests we receive from prospects, even when the project doesn’t go ahead? Also, have we ever collected feedback from our clients about what they do and don’t like about Open edX? You two have been around longer than I have so I figured you might know!
Aside from effects of this that others already listed, it also impacts sustainability management to some degree. Specifically, it makes sustainability previews somewhat unreliable because the data that relevant calculations depend on is incomplete.
For example, when compiling the sustainability preview for Sprint 312 at the end of Sprint 311, 35% of tickets in these two sprints had no remaining estimate.
Shifting the end-of-sprint schedule by a day
This would help with reliability of sustainability previews (which are always posted on Monday W3) in that on average, the percentage of tickets with no remaining estimate should be much lower by Monday W3.
It would make sprint planning for ASU MoE tighter – the final sprint planning meeting for the following sprint happens on Wednesday W2, more or less right before my EOD.
In the current setup I’m able to help @paulo on Thursday W2 with creating tickets for any items that came up during the meeting.
With the proposed setup that won’t be an option anymore; @paulo will need to create tickets himself right after the meeting on Wednesday W2.
Running out of work during a sprint
, and also:
Look through the list of blocked tickets and ask assignees if there is anything you can do to help get them unblocked.
This includes pinging reviewers on upstream PRs. (In theory, assignees should do this for PRs waiting for upstream review at least once per sprint, but experience has shown that it’s easy to forget. Which doesn’t make it any less important… )
Sprint planning and management for Serenity
The scope of cell management roles (including sprint planning and sprint management) is already smaller for Serenity than for other roles, see Cell-Specific Rules > Serenity > Roles.
So maybe this is mostly a matter of making sure that Serenity’s checklist items for sprint planning and management (as currently defined in Listaflow) match cell-specific definitions of these roles?
Generating and finding tasks
That might be helpful, yep.
However, to save some overhead it might also make sense to try and double-down on our existing processes:
Right now, each epic owner already has a recurring task that involves creating tickets for upcoming sprints – the epic itself.
(When using appropriate Crafty directives to block out time for epic management, I think SprintCraft takes these into account when calculating remaining hours to fill for the following sprint, but maybe I’m misremembering. CC @Agrendalath)
So maybe 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?
At least in the coming weeks it would be useful to try and do this across the board, and for several sprints in a row – with recruitment for Bebop being so successful lately (), the cell is a bit overstaffed going into the holiday period, so sourcing more billable work by planning ahead would be a good idea.
And while I don’t think this type of work should be left until the end of the sprint, epic owners could report results of their efforts when posting their bi-weekly epic updates (by listing tickets to work ahead on). Epic planning managers could then take care of checking that epic updates include relevant info, and follow up as necessary.
I think creating a last resort backlog is a good idea. When there are no tickets, even a single ticket can make a difference.
That’s a great point. Having had the experience of transferring the ticket to someone close to the end of sprint, this should definitely be put into the docs if not already there.
from me on this as well.
On this note, 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.
I think is worth to always have at least a small amount of task in this buffer. Especially tasks that could also be used as Trial Projects. If we grow and seek balance, we will constantly bounce between a little under/over capacity. I think this will also help us to have better Trial Projects prepared beforehand. If we opt for a buffer, the trigger for new tasks is simply “we have less than x tasks in our buffer”
I agree with the points raised in the thread and the most visible aspect of less workload is coming from the client side which may be in some periods of time higher and sometimes lower but cannot be eradicated entirely. However, based on sustainability, we can have some additional steps taken out internally for the employees with permission of a certain manager (optional) to guard the budget.
Below are the points that I have came up with after brainstorming session:
Learning Budget (3h/month/36 hours per year):
Could be related to anything or a list provided by opencraft that the members can spend to learn about. For example, android development, devops work.
Rotating Dedicated Manager for Creating Open Source Contribution Tickets (1h/sprint):
A specific manager who creates tickets for open source contributions (opencraft) so the users can fill in their hours in their sprint and if not (accumulates to their number and can be worked on anytime when they don’t have enough work).
Mentoring Sessions/Knowledge Sharing (1h/sprint):
There are internal tools developed like Listaflow, Groove, Sprintcraft. A recorded mentoring session for any of these could be helpful for newcomers joining in or even the old members shifting to a new project. These sessions could explain about the architecture and decisions which were taken, could go over the code and explain about it like how CI/CD is set up.
Most importantly, I have seen over the chat, newcomers struggling with setting up the environment, it could probably make sense to dedicated few hours into the mentoring session of onboarding course, so that the mentor can setup a basic tutorial for setup or it could be a slide or written article that could help in the future as well.
Pair to Pair (1h/sprint):
Seniors or Experience Members based on context could pair with members to transfer their knowledge relevant to a ticket. The assignee could create subtasks for the given task where they can request pair to pair programming to learn from their reviewer about the project.
Content Writing for OpenCraft (Blog) (1h/sprint):
Sharing something about internal work (Listaflow Updates), culture update, an interesting issue encountered by OpenCraft
Similar to what we have for an open edx conference but for writing could be shared on blog.
Expanding Internal Documentation (1h/sprint)
All of these points, if implemented, can generate around ~15 hours additional per month for an individual which roughly means that out of 8/9 sprints, your 1 sprint can be taken care of from OpenCraft if there’s not much work. Though this could put strain on OpenCraft budget but with guarded measures can help individuals resulting in a better environment and mental health. Also, the side-effects of the implementations can result in OpenCraft marketing, knowledge transfer can reduce the actual time spent in the tickets where one spends a lot of time gaining the context as well as experience members get to impart their knowledge.
I agree with the last resort backlog idea like everyone else.
Additionally, during the sprint if we run out of tasks, one more option would be to ask epic owners if they can create a task or two for the next sprint for them to work ahead on, while ideally the tasks should have been created before the cut-off date and for the current sprint but issues like task dependency, client approvals, budget can block epic owners from creating them. Few days into the current sprint might provide them with some time to come up with more tasks.
I like the concept of having a Last Resort backlog, and agree that it should probably used rarely, ideally working on tasks from client work or our other backlogs.
From my experience, I noticed that when I run out of tasks its generally in the middle of the sprint, either because something was blocked or I was able to complete a task much faster than expected, I usually ping on the teams mm to see if there is anything I can pick up, in some cases there isn’t anything to work on, and new tickets can’t be created under the epic because things are block on client approvals or dependancies on other tickets.
It might be worth also trying increase the frequency in which we communicate with our clients, to get approvals from them or to suggest working ahead on certain (future?) tasks, though this is probably harder said than done. If we can create tasks that would benefit the client and the broader openedx opensource community, such as improving a process/tool/documentation, and the client is willing to fund it (even partially?) that would be a best case scenario for a Last Resort task, we can always have pre-approved in the backlog when it is needed.
I especially like this idea, as it leaves Friday as a day to communicate about any issues during the estimation session and assignment of tickets, which to me seems better than the weekend between the estimation session on Friday and the last day of the sprint on Monday.
I’m not very sure about the last resort backlog helping this much. As noted - these tasks haven’t being prioritised till yet because of scheduling, or lack of information/budget, and ideally shouldn’t be worked on during the sprint.
Maybe we can add more data to tickets so browsing the backlog could be more informational?
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. One suggestion could be to create a new sprint to the purpose of ‘Ready but not in the schedule’. This one could act as a last resort backlog, after the backlog has been emptied out.
For tickets still in planning stage, we can mark them as draft in some form, as they ideally should be in neither of those lists.
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.
, and also:
)
), the cell is a bit overstaffed going into the holiday period, so sourcing more billable work by planning ahead would be a good idea.