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.
I left the instructions on the ticket.
1 Like
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.
2 Likes
+1 for the last resort backlog
+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.
2 Likes
@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.
2 Likes
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?
2 Likes
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 .
Sounds great!
+1 to this too.
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.)
1 Like
Estimations
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.
Tracking Open edX feature requests
@DouglasDraper Great idea!
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.
1 Like
If this happened, let me know - right now there are quite a few, including some backlog in the “last resort - proposed” list.
Maybe the sprint-planning one? This way it already exists, and most of us should already be in it? Mattermost
Is Bebop still recruiting? Shouldn’t we pause this until we have some new clients/projects in the pipeline for people to work on?
@jill We paused recruitment a while back, in the sense that we stopped taking new candidates. But when that decision was taken there were a bunch of candidates already in the recruitment queue. Many of them finished their trial projects successfully, and so Bebop has had additional people trickle into the cell even though it is no longer actively recruiting.
Sounds good
Great, thank you
This looks really interesting to me! I would love to dig into it a bit more early next year if possible. @antoviaque Could I create a ticket to watch the video and do a bit of research into what was tried and the possible reasons it didn’t work out?
@Ali Definitely, don’t hesitate - this is also great core contributor work btw :)
1 Like
@tikr Note that I didn’t have room left in my sprint this week, but this should be getting in next week’s sprint.
@antoviaque Noted 
For the items that I’ll be taking care of I have STAR-3409 in the sprint starting tomorrow.
1 Like
I have created a PR for implementing the changes in the handbook:
Anyone is welcome to review it – I have pinged in particular @tikr @ChrisChV @paulo @mtyaka as reviewers, as this affects some of the sprint planning and epic planning managers duties.
4 Likes
I might be missing something but it looks like SprintCraft is already factoring in remaining estimates when assessing the workload for the upcoming sprint: For each cell member, hours displayed in the first three columns (My Work, Reviews, Upstream) seems to include remaining estimates from tickets in the current sprint.
@Agrendalath Could you confirm?