@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
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.
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
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. 
1 Like
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.
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
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
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!
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?
- SprintCraft @artur @tecoholic @farhaan @kshitij @Cef @navin @paulo
- SprintCraft @ChrisChV @pooja @rpenido
- SprintCraft @mtyaka
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 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.
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
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!
Ok. Then I’ll take it upon myself to set it up.
Unestimated tickets
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.
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.
1 Like
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.
1 Like
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.
3 Likes
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.
1 Like
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.
2 Likes
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 have nothing else to add.
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.
2 Likes
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.
1 Like