This is a question that is often asked by project managers when first understanding iterations/sprints.
0
|
|
|
|
1
|
Two weeks is our magic number. One week was not enough time to do the full cycle to get to "Done", which required development, code review and QA. The sprints would be almost done every time and I feel quality suffered. Two weeks allows enough time to get QA done and address any required changes found during testing. We have to push back sometimes to keep the Product owner from changing priorities mid-sprint but next sprint is always the more attractive alternative. |
||
|
|
|
1
|
The "business" aspect of it is there but there is another major piece - what is your team comfortable with? A client may never change priorities but the team might decide 4 is too long. Again, I would have to suggest adapting. That is always the main theme of Agile: fine tuning your process and making adjustments as necessary. It also depends on how comfortable the team is with planning. New teams are better off starting with a one week sprint - it's less to commit to and you can get a good idea of what your velocity is. If you start too high too early, then you are likely to miss your sprint goal and get an inaccurate velocity. Once you notice your team has been hitting your commitments pretty regularly, relax it to two weeks - this means less interruptions to the developers. |
||
|
|
|
0
|
The classic answer to this is to look at how long the "business" can go without changing priorities. Ideally this is two weeks or longer. For example: if the team chooses a four week sprint/iteration length and the business routinely changes priorities every two weeks then the sprint/iteration has no chance of being successful. |
||
|
|
|
0
|
If I remember correctly, it is Kent Beck who uses/used to ask "how much work can you afford throwing away because it wasn't what you needed?" |
||
|
