假设一个由 5 人组成的团队每冲刺可以提供 10 个用户故事。在冲刺期间，每个用户故事通常会在每日站会上讨论几次，至少两次：在开始和结束时。也就是20次。如果团队由 10 人组成，则每个冲刺可以交付大约 20 个用户故事。在这里，每个用户故事在冲刺期间至少讨论两次，总共 20 x 2 = 40 次。
在每日例会期间，每个团队成员只有一半的时间可用于处理每个用户故事。另一个风险：对每个用户故事的关注度较低，因此清晰度较低。
第三个轴线涉及敏捷原则：在开发团队内部和与开发团队共享信息的最有效方式是相互交谈。更大的团队会生成更多的文档，通常是为了确保每个人都在谈论同一件事。与多个人的相互沟通更加困难，通常通过电子邮件进行，并且可能 阿曼电报数据 造成混乱和错误。记录需要更多时间，这意味着实现用户故事的时间更少。如果质量控制不足，文档的解释也会有所不同。风险：更多的文档和书面交流，更少的个人接触。
此外，诚实也是团队成长过程中可能受到影响的一个因素。当团队成员遇到挫折时，很可 能在一个大型团队的每日例会上不会讨论或不会正确讨论这个问题。由于每个团队成员可用的时间较少，因此淡化问题或试图隐藏在你无法控制的事情背后是人性的反应。然后团队就会过于专注于确保每个人都能在规定时间内发言。风险：质量下降和交付不稳定。