@tikr Ah, great - thanks for correcting me.
How are we doing then in terms of role caps for Bebop now? If moving one person to Falcon would put the role caps of Bebop in the red, we probably aren’t too far from reaching them no?
Many people don’t have enough work this sprint.
If anyone has tickets that can be worked on, please let us know.
3 Likes
@demid Thanks for bringing this up.
@tikr @Fox This seem to be a recurring concern, despite the new projects starting. Would you be able to take a task to look into this more deeply? Ie understand concretely the exact level of difference between capacity and available work? And try to find solutions - or at least establish a planning to solve this depending on the new projects starting?
It might also be worth looking into which epics could split up more tasks, establish specific numerical goals in that matter, and track it more closely - rather than having it as an uncoordinated surprise for cell members each sprint?
If there are blockers on epics/projects with work but which prevent it from being started or split, it would be useful to highlight them as well as suggesting plans to fix those.
We have five people on the DD roster for Bebop currently. That’s more than we had in the past, where the cell would sometimes only have 2-3 people on the roster for a while.
Since we’ve recently gone back to doing some small to medium-sized development projects, there’s been quite a bit of fluctuation in terms of role load. So I think that the roster should continue to stay open for the foreseeable future (assuming that we stick to the decision of only moving newcomers to Falcon).
–
In terms of better understanding why lack of work seems to be a recurring issue: Some newer epics generating less work than originally expected has definitely been playing a role.
One thing that I found surprising when looking at the current sprint, though, was the total number of tickets on the board. Even when filtering out tickets with a status of Deployed & Delivered or Done, there’s still 130 tickets in the current sprint.
From a high level it seems like an average of 130 / 11 = ~12 tickets per person would have the potential to fill everyone’s hours?
But there’s probably something I’m not seeing. If everyone in @bebop who’s been in a situation where they felt like they weren’t getting enough work (for this sprint or some previous sprint) could share their perspective on that particular point, that would be really helpful.
CC @farhaan
2 Likes
I’m not sure what is the best way to calculate this. I did this the “dumb” way:
- 177 tickets in BB project in BB.300 sprint
- 100 of those tickets are in Blocker, Recurring, Merged, D&D or Done, leaving 77 tickets in Backlog, In Progress or Internal Review
- 11 more are “Developer review”, leaving 66
- 5 more are FF and DD placeholder tickets, 61
There are also a couple of Recruitment tickets, and tickets from MNG and Serenity cells (these only have a reviewer from Bebop).
I know these are rough numbers, and may be some of the blocked tickets are going to bring some work this sprint, but as far as I can tell, for some of the folks the problem is exactly that the work is currently blocked.
And even then, ~60 is far less than 130.
OK. Can I ask, in any case, to not close it without involving me? I’d like to keep an eye on this.
Thank you for digging into this. It sounds like a lot of tickets - that does look like a lot of tickets in a sprint. And @maxim seem right to point out that a lot of those are in the “blocked / upstreaming” status (64 tickets!). Issue Navigator - OpenCraft – are we really expecting that all those blocked tickets are likely to bring work this sprint? Otherwise they should be in “Long External Review/Blocked” – which is also showing a huge backlog! It would be worth spending some time to see if any of this can be unblocked or is miscategorized.
It also looks like all sprints are carrying 22 old archived tickets that haven’t been updated in a while? I think sprints don’t close archived tickets, they need to be removed from a sprint to stop being rolled over from one sprint to the next forever: Issue Navigator - OpenCraft
@tikr In any case, can you schedule a proper task to spend time digging into this next STAR sprint, with input from @Fox and @braden (and maybe other epic owners?) on upcoming projects, and their blockers to be able to split out more work from it?
@antoviaque, SprintCraft removes archived tasks before closing the sprint. The issues you’ve linked (except for BB-7470) are all subtasks, though. In Jira, the Sprint value is inherited from a parent task, so it’s impossible to remove a subtask from a sprint. The only way is to close the parent task.
For those looking for tasks, @Fox just posted this in Mattermost:
If anyone is still looking for hours, please take Log in - OpenCraft . I’ve not been able to start on it and it’s been sitting there for too long as I’ve been addressing a discovery that’s blown up.
@antoviaque Sure, no problem. Notifying you when the roster closes is part of epic planning responsibilities (see template for bi-weekly epic planning and sustainability management), so this is already on @farhaan and I’s radar 
The roster has never been fully closed since we added that step.
The next two STAR sprints will be short ones for me. I’ll be away June 8-14, so STAR.118 and STAR.119 will be limited to two and three working days, respectively.
So STAR.118 won’t work, but I can plan to get started with the work in the second half of STAR.119.
In the short term we have two more tickets that ASU MoE would like us to inject into the current sprint:
Who would like to take these?
CC @paulo
Thanks! I have taken this one.
@tikr I think we need to solve this earlier, for the upcoming sprint - that wouldn’t be fair to leave Bebop without enough work for that long, when we know of the issue. Can we look at priorities, and push back other tasks/topics, to make room for this? The issue is pretty urgent and important for several team members.
FYI there is a related discussion currently at Log in - OpenCraft
And I’ve got another ticket here. Pooja was initially assigned to be DD for this sprint, but since she got inundated with discoveries for a different reason, this one’s up for grabs.
Thank you @sathis and @kaustav for taking the ASU tickets mentioned above.
@demid @farhaan @keithgg @maxim @navin @pooja Who would like to pick up the reviews for these?
1 Like
I could drop STAR-3102 and STAR-3146 to make room for further investigation in the short term.
Alternatively, we could consider giving this work to someone from Bebop – while it is the kind of work that we’d consider cell support by default, that doesn’t mean that someone else can’t take it on? Especially in the current situation, where members of Bebop are actively looking for work and my availability over the next couple weeks doesn’t match the timeline that you’re proposing very well, it seems like that approach would allow us to kill two birds with one stone?
In terms of improving things in the short term (i.e., for the current sprint and the following one), it looks like there’s a couple more things we can do. I’ll follow up with another post about those.
Here is a list of things to do / factors to consider that should contribute to increasing Bebop’s workload over the next few weeks:
- If @braden @jill and @ChrisChV agree, we could move @sathis to Falcon. As mentioned in this reply to the conversation linked above:
He does not have any roles yet, so the ripple effect created by this change would be minimal – no increase in role load for other members of Bebop, and no need to shuffle roles around, change epic and client ownership, etc. Plus, any development work that he would normally do for Bebop would become available for other members of the cell to pick up.
- We are ready to start work for Aquent. From @Fox’s latest update:
We need … a client owner who can provision their instance and then work with them moving forward. They don’t have need for a ton of customization (yet) but they do want to have an instance where they have full access (AWS cluster) and then these two customizations:
“We need to request that 10 failed password attempts will lock out an account to prevent brute force attempts. We also need to request anti-virus/malware protection on our instance.”
From there, they’ll engage us for consulting advice and assistance when they’re in a bind, but want to handle most of the customization on their own, tapping us for advice as needed.
- @bebop Who wants to take this on?
- It might be possible to start working on the Olive + Palm upgrade. @kshitij Since Palm branches have already been cut, could we schedule a first batch of tickets (for branch prep etc.) for Sprint 301?
- @Fox is handing off the BB-7203: HMX Lessons and Pathways epic. He recently worked on a discovery that might unlock more development work for Bebop in the coming weeks (assuming that we won’t get blocked waiting for budget approval and/or paperwork to be signed here).
- Keith will be leaving the team at the end of this sprint.
Lastly we have some additional tickets from ASU MoE that we could consider pulling into the current sprint. However, at over 30 tickets the amount of in-progress work for ASU MoE in the current sprint is quite large already. So before increasing complexity further by adding even more tickets, it would be worth making sure that all existing tickets are either completely done or fully blocked. (If you’ve been waiting to hear back from the client for a few days, now is the time to check back in with them )
1 Like
@tikr Great idea Maybe see if you can find someone from Bebop to take on that task, and keep the option to reprioritize your upcoming sprint if it ended up not being possible for some reason? But it’s true that given the extra capacity Bebop has, this should be possible - maybe even as a sprint insertion now, to those looking for work?
For the tasks to reprioritize - STAR-3146 can be delayed yes, though for STAR-3102 we are already super late to deliver this to ASU so this needs to be completed quickly. It doesn’t look like this will be necessary, but if you need the time is there another task you could delay?
@antoviaque OK, I created BB-7519 and put it into Sprint 301 for now.
@bebop Please pick it up and pull it into the current sprint if you have room. Otherwise I’ll pre-assign the ticket the day before my time off starts (Wed).
@antoviaque Noted for STAR-3146 and STAR-3102. I don’t have any other ticket that I could delay. Especially for the first couple days of Sprint 300b / STAR.118 there’s a bunch of stuff from my recurring responsibilities that I’ll need to take care of.
Either way I think the points that I researched last week and listed above should provide a good starting point for finding more work.
@tikr Thanks, that works. FYI, in terms of remaining priorities arbitration, solving the capacity allocation gap comes before any of the recurring responsibilities - it’s never great to delay those, but this is important and blocking enough structurally to be worth some disorganization on other less important topics.