In Scrum, the scope of work for each iteration is timeboxed to 1-4 weeks. Currently the VE team (and mediawiki development in general, I think) works on a weekly release cycle, although not all teams participate weekly. This has some similarity with a week-long Sprint and also some with a a week-long release cycle. Either way, VE needs to organize its backlog on a longer timeframe and there's no particular reason to use timeboxed increments. The current plan is to use prioritized "tranches", where each tranche is an internally prioritized list of tasks all related to a single goal. E.g., Tranche 1 might implement the first 1/3rd of a goal (such as rolling a new feature out to all languages); Tranche 2 might completely address one complicated problem, and then Tranche 3 might by the next 1/3rd of rolling out the new feature from Tranche 1. Tranches don't need to be the same size. Once Tranche 1 is done, Tranche 2 becomes the most important (no renumbering, just roll forward). Since the VE team has a steady flow of high-priority bug fixes, there will also be a permanent Tranche 0, and developers will not start on Tranche 1+ unless Tranche 0 is empty or otherwise fully addressed.
- what's going to go wrong with this?
- What is this trying to solve that Sprints solve better?
- What does this solve better than Sprints?
- Are tranches really an alternative to Sprints, or just a different way of sorting the Product Backlog?
- We also have the concept of an "Unplanned" tag. How does this relate?