How many sprints ahead do you plan?
We are moving from Kanban to Sprints.
We have a big backlog of over 200 items (related to a few different projects)
In Feb we will be moving to 2 Sprints and my question is how many sprints do you plan.
We will be using Letters for our Sprints - i.e. Week 1/2 would be Sprint A - Week 3/4 Sprint B etc.
We will be starting sprints in Week 5/6 (of the year) so we will start with Sprint C - I'm included to plan/map out 3-4 sprints ( C / D / E/ F ) so stakeholders / my team knows what is coming.
I'm not sure if this is the best thing to do, As Sprint planning meetings would become odd - having to plan for a month - 6 weeks away -
Should I just take each sprint as is comes ?
Thanks for any advice given.
We have a big backlog of over 200 items (related to a few different projects)
In Feb we will be moving to 2 Sprints and my question is how many sprints do you plan.
Let's step back from that for the moment. How many products do you intend to plan?
We have 5 Products ( websites brands )
They have on going updates / features being planned for them.
so adding onto what Ian said, if you've got 5 products, you should be breaking your backlog down by the Product. This helps reduce complexity and confusion. Ideally you'd have a single team per product.
Are you changing to Scrum or are you just doing Sprints? There is a big difference between the 2 that many people don't realize.
I'm also curious why you're using letters for naming your sprints instead of numbers. What happens when you get to Sprint 27, would you go to AA, AB, AC, etc etc?
To answer your initial question of "How many sprints ahead do you plan?", that really depends. The teams I'm working with are starting to use the Nexus Framework for scaling and we are going to be planning at a high level 2-3 sprints ahead. That does not mean it is concrete and won't change, it also doesn't mean that we are going through and tasking things out prior to the sprint the items will be worked on. We are basically taking the features and identifying when they will most likely be worked on. This helps because there are going to be dependencies and it's easier to track when you plan a little ahead. I do not suggest detailed planning other than the current sprint and I don't suggest going farther than 3 sprints at a high level because things will change; not might, WILL.
My 3 cents, if you want to use Sprints (or maybe it would be just timeboxed iterations?) in your Kanban, then I sense here a desire to take a control on scope or something like that. But doesn't Kanban have already those things built in?
When you wrote Kanban, did you mean only board with some columns, or you do actually use Kanban as it should be used? With WIP limits, flow management, transparent policies on column borders, tracking Cycle / Lead time, throughput, maybe some SLAs etc.?
Why do you want to use Sprints / Iterations? And following Curtis question:
Are you changing to Scrum or are you just doing Sprints? There is a big difference between the 2 that many people don't realize.