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.