在整个sprint开发过程中要做到资源合理和充分利用，并给予ST预留闲置时间。
1. 每天工作时间为8小时，可充分利用时间为80%~90%，即8*80%~8*90%=6.4~7.2小时之间。
一般的，如果整个团队配合时间较长，可以考虑资源利用率在90%，如果是新团队或者项目刚给启动，建议资源利用率80%。在团队成长过程中逐步增加资源利用率，最多不要超过90%。防止任务过多影响sprint交付。
2. 在sprint前确定有多少人，没人多少小时可投入到开发中。例如请假、公休日要排除在sprint外。
在整个开发过程中请假是不可避免的，尽量在sprint开始之前确定请假计划。如果在sprint开始后，出现请假，可以根据实际情况调整开发任务，合理利用闲置10%时间，做到sprint正常交付，如果出现突发大量资源异动，则需要请PO和PM确认是否将部分story移到下一个sprint。
正常情况下我们可以根据公休日的情况，将每一个sprint调整为等长的工作日。特殊情况，例如多国合作开发，每个sprint会是相同的自然日，而非工作日，此时需要在sprint之前考虑公休日，按照实际情况接收相应的point
3. 一般情况下这个team是不包含测试的，如果包含测试人员需要将开发与测试分别考虑，建议测试与开发的配比为1:4
测试人员加入到team中，会影响整个后期维护，测试人员比例越高后期维护开发人员工作量越小。理论上有测试的介入，开发阶段解决的bug会更多，测试阶段bug会相应减少。
例如：以下为6个开发，无测试或1测试或2测试，建议开发人员可最大使用的资源占比
| 无测试 | 1测试 | 2测试 | |
| DEV | 90% | 90% | 90% |
| SIT | 70% | 80% | 85% |
| UAT | 80% | 85% | 88% |
案例：
sprint 周期：21自然日
Scrum Team：1 SM， 1 TL，6 ST
point：1pts = 8h资源利用率：90%
正常情况下
这个团队可以接受的工作量为： 6 * (21 - 6) * 8 * 90% = 648hpoint 数为 648/8 = 81pts
理论上如果每个sprint接受81pts 的工作量，则这个团队可以正常完成。
假设当前sprint遇上国庆长假：
这个团队可以接受的工作量为： 6 * (21 - 6 - 3) * 8 * 90% = 518.4h
point 数为 518.4/8 = 64.8 pts理论上这个sprint接受64pts的工作量，则这个团队可以过一个完美的国庆假期
如果团队中增加测试人员，理论上不影响团队的整体工作量。