The key concept: To understand the optimal iteration length in agile projects. Also we can understand the side effect and importunateness of the optimal iteration in agile projects.
What exactly is the optimal iteration length in agile project?
The length of the iteration depends on the amount of time the users can go without seeing progress and providing input. Some core mechanics require a lot of feedback from outside, so maybe one or two week iteration is better. Some teams don’t need such a rapid cycle of feedback especially production teams and so four weeks iteration is fine for them.
Team Experience affection
The experience level of a team needs to be considered when selecting the length of iteration. Teams that are new to agile often want to have the longest possible iterations. Experienced teams will do a bit of each of these things daily which is a better way to work. It creates better results and allows the team to discover better value during the iteration.
Ability to plan the iteration
If the iteration goals have a lot of uncertainty and experimentation that needs to be done (in the form of spikes, or time-boxed tasks) then the iteration should be shorter than one with less risky goals. Risk implies that the solution might be significantly different from the one anticipated at the start of the iteration. It’s better change direction (or even backtrack) after two weeks than four in this case.
Balanced Intensity
sometimes four weeks is too long to give a team to work. This is especially true of teams that are new to agile. As described above, new teams will do mini-waterfall on iterations at first which leads to a pretty lax mini-design phase up front and an intense debug mini-crunch phase at the end. Teams will find what works best for them over time.
If the iteration goals have a lot of uncertainty and experimentation that needs to be done (in the form of spikes, or time-boxed tasks) then the iteration should be shorter than one with less risky goals. Risk implies that the solution might be significantly different from the one anticipated at the start of the iteration. It’s better change direction (or even backtrack) after two weeks than four in this case.
Balanced Intensity
sometimes four weeks is too long to give a team to work. This is especially true of teams that are new to agile. As described above, new teams will do mini-waterfall on iterations at first which leads to a pretty lax mini-design phase up front and an intense debug mini-crunch phase at the end. Teams will find what works best for them over time.
No comments:
Post a Comment