Iteration length

Get Started. It's Free
or sign up with your email address
Rocket clouds
Iteration length by Mind Map: Iteration length

1. overview

1.1. Choose a length that’s too long, and it will be hard to keep change out of the iteration

1.2. Choose a length that’s too short, and a team may struggle with completing significant work within the iteration or weaken their definition of done to do so

2. quickly

2.1. Before you start thinking about changing the length of your iteration cadence, check that your domain/context hasn't already a set iteration length. This is important in a context where teams work together – a standardised iteration length helps in coordinating teams.

2.2. It's good to question your iteration length and experiment with the right length, but once you have a found a good fit, you should look to stabilise it and not change it (at least not each iteration).

2.3. Do NOT (i.e., never) change your iteration length during an iteration, e.g., you should not start with the intention to do a 2 week iteration and then half way through it decide that you will make it 3 weeks to account for the work left.

3. who decides?

3.1. team

3.2. but IM if no consensus possible

4. decision factors

4.1. rate of change and ability to look ahead

4.1.1. priority changes between initiative level (MVP and Feature level reprioritization)

4.1.2. uncertainty within an initiative (story level reprioritisation)

4.1.3. length should: match the natural rate of change to iteration backlog you should be confidence that you can stick to your plan for that iteration, changes should be exceptional match the frequency needed for feedback (to ensure work is going in right direction)

4.2. sync opportunities with other teams

4.2.1. some initiatives require multiple teams: it's advisable to perform iterations in lock step, at the very least the same iteration start day and a compatible multiplier, e.g., iterations start on Tuesdays and team X has 1 week iterations and team Y has 2 week iteration, not starting on different days and incompatible mulitplers: 2 and 3 week iteration lengths

4.3. team learning

4.3.1. shorter for faster learning, e.g., capacity, CI experiments (accuracy of estimation, etc.)

4.3.2. shorter for higher team satisfaction and morale due to better focus and lower WIP (some empirical evidence exists to support that claim)

4.4. WIP limit

4.4.1. shorter encourages lower WIP limit lower WIP means better flow efficiency

4.5. customer benefits from work

4.5.1. shorter => better compound interest

4.6. rate of end-to-end delivery and size of meaningful iteration goals

4.6.1. iteration length shouldn't be shorter than lead time or teams ability to deliver meaningful pieces of work

4.6.2. factors: maturity of work breakdown practices impediments due to complex dependencies and slowdowns

4.7. overhead of ceremonies

4.7.1. ceremony length scales to iteration length (roughly same % time spent) but frequency of ceremonies increase

5. visual