Topic on Talk:Team Practices Group/Flow

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.

1. what's going to go wrong with this?
2. What is this trying to solve that Sprints solve better?
3. What does this solve better than Sprints?
4. Are tranches really an alternative to Sprints, or just a different way of sorting the Product Backlog?
5. We also have the concept of an "Unplanned" tag. How does this relate?

1. I don't see any huge problems.
2. Timeboxing can force some healthy decisions to be made.
3. Planning more than one sprint in advance seems like a fool's errand. This allows a longer time horizon of planning, without fitting neatly into sprints.
4. This could be an alternative, if developers literally work directly out of the tranches. Or it could just be a different way of sorting the backlog, if the next process step is for the PO to move tasks from tranches 0 and N into a current sprint workboard backlog. (And developers would pull tasks from there.)
5. The unplanned tag doesn't apply to the tranch board being described here. It would apply if there is also a sprint board (per #4).

I am still curious why you chose the term "tranche".

1.) My first concern would be a lack of predictability. The team would also loose the advantage of a steady rhythm. There is also something to be said for the pressure to create a shippable increment every sprint.

2.) I don't have context on the original goal of this term. However it could be accomplished with the text book application of "Sprints" a properly prioritized backlog and the concept of "Release Planning".

3.) This sounds like an attempt to create a stage and gate system. It may work in some agile frameworks. However it takes away the teams' ability to commit to work in a given time period.

4.) If you are thinking about tranches as a collection of epics, then they are more closely related to "Releases" in the classic scrum sense. But if there are time periods as well as groupings of work, you are leaning towards a traditional stage and gate process.

5.) I wanted the "Unplanned Sprint Work" tag so that I could do data analysis for my team. They have had a series of emergencies that interrupt their work. They also sometimes pull in their own work after the sprint starts. This is merely a tag for me to track these items. We will be looking at them in each retro to discuss what happened and how to improve. I'm going to be adding quite a few tags to phabricator so that I can do detailed analysis on different types of work. As trends develop, I'm going to propose fixes (and hopefully increase our velocity).