project-management - Team size and project iteration length

Question

Do you think that project iteration length is related to project team size? If so, how? What other key factors do you use to recognize correct iteration length for different projects?

Answer 1

Iteration length is primarily related to the teams ability to communicate and complete a working version of the software. More team members equals more communication channels (Brooks's Law) which will likely increase your iteration time.

I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.

Ultimately, the iteration length will depend on the features you wish to implement in the next iteration, and in the early phases your iterations may jump around from 1 week to 1 month as you become comfortable with the team and the technology stack.

Answer 2

One of the main drivers for short iterations, is easing integration between modules/features/programmers. Obviously, the bigger your team, the more integration you will have. It's a tradeoff: short iterations mean you're integrating often, which is good - BUT if its a big team you'll be spending a LOT of team on integration overhead, even without new code. Longer iterations obviously mean more integration each time less seldom, and a lot more risky.

If your team is very large, you can try branched integration, i.e. integrating small subteams often, and integrating between the teams less often... BUT then you'll be having inconsistencies between branches, and you lose much of that benefit right there.

Another key factor to consider is complexity - obviously complex, backend systems are riskier integration, simple Web-UI pages are less risky.

(I realize I didnt give you a clear cut answer, there is none. It's always tradeoffs, I hope I give you some food for thought.)

Answer 3

My experience is that the length of the iterations are somewhat dependent on team size,

External dependencies, like in cases where we had to integrate with in house systems that was not using a iteration based development cycle (read waterfall) where another factor we observed.

Our team were real noobs when it came to iterative development, so in the beginning the iterations where really long (12 weeks). But later on we saw that there was no need to worry, and the iterations shrunk considerably (4-6 weeks).

So another factor in how long the iterations are is how familiar you are with the concept of iterative development.

Answer 4

可以完成多少工作是有关系的，但这里还有一些其他关键因素，比如他们在处理什么类型的项目，例如 Windows 应用程序、控制台应用程序或 Web 应用程序以及代码库的开发方式与当前团队的风格相比，在规模、复杂性和风格方面，以及团队在方法论和他们正在做的工作方面拥有哪些专业知识，因为缺乏经验可能会让每个人都精通流程，成本很高。

Answer 5

我认为 2 周的迭代，无论您是否交付给客户，都是一个很好的目标，因为它可以进行非常好的健康检查。

2 周的迭代对我和我通常做的项目类型来说是最舒服的，但我不同意不交付是一个好的结果 - 重点需要保持在“工作软件超过流程”方面。

如果产品所有者/用户不可用，我会考虑延长迭代时间，即使只是每隔几周展示一次，因为快速迭代在技术方面允许的相同健康检查需要在参与方面进行这生意。

Answer 6

迭代长度应该由许多因素决定……团队规模实际上只是“迭代开销”考虑的一部分。

这篇文章解释了其中的许多。

重要的国际海事组织：

1. 总发行长度
2. 优先级可以保持多长时间不变
3. 迭代的开销