So we have a couple programs that have teams that are Scrum and Kanban. I am trying to figure out the best/correct way to plan throughput forecast for Kanban Teams in the Team Planning Feature. Do you just create a single Iteration for a 10 week timebox, add Planned Velocity, and slot in the stories until velocity is full?
For Scrum team we would have 5 iterations and we slot the stories using the Planned Velocity as a guideline and the above is the only way I can think of to complete similar exercise for Kanban Teams. #kanban #teamplanning
One question that comes to mind is why you'd try to forecast 10 weeks of work for a Kanban team. If the team really works as a Kanban (continuous flow) team then aren't they just pulling the next story in line?
I have a mixture of Scrum, Scrumban and Kanban teams in my subscription and the pure Kanban teams simply don't use timeboxes or Team Planning. If I know a Kanban team's throughput and cycle time metrics then I have everything that I need in order to predict what we can accomplish in the next 10 weeks.
If you feel that you must use Team Planning then your idea of a single 10-week iteration would technically work and let you use the tool but it seems like a lot of overhead for little value. If there are more details about your use case that you'd like to share then please feel free and we can continue the conversation. Hope that helps.
Fair Question Eric, the reason is that these teams are part of a Scaled Agile Train. We need to still plan the work for the 10 week PI and make sure it aligns to the PI Goals and adjust as needed. These are mainframe development teams and Scrum doesn't work for them which is why we are choosing to use Kanban. I agree to your point of using throughput for predictability, but we still need to plan.
Given those constraints I think that your plan of having a single long iteration may be your best option. I do think though that it might be worth (nicely) challenging the mainframe development teams regarding the assertion that Scrum won't work for them. If you can plan stories against your velocity for a 10-week stretch then I'd think that it would be even easier to break that down into smaller iterations. We have a very similar situation with mainframe development teams as part of an Agile Release Train and we treat those teams as scrumban teams, planning to a two-week iteration cadence but using a set of customized Kanban states to let them preserve a familiar develop/test workflow.
The teams have been working as Scrum Teams for almost 2 years. Splitting the stories across Sprints especially multiple Sprints due to multiple reasons but mostly QA testing time is deflating to moral among other things. So now we pivot to align methodology to work and not work to the methodology. Thanks for for feedback and validation of my assumption on single iteration.