1、工作量计算逻辑：
原始待办事项：
预估2个冲刺，如下图所示：
Sprint1的故事点计划工作量5，空闲工作量28.如下图
Sprint2为预估冲刺，指的是预估待办事项在后续冲刺的预估计划，后续冲刺预估逻辑如下：
一： 确定冲刺预估总量（如图为30）
二： 按照图1的待办事项从上到下依次选择有故事点的故事进行加和，找出最接近30并且小与30的值，伪代码如下：
Int sum = ; //计划故事点总和
Int currentStoryPonit; // 当前故事的故事点
Int total; // 故事总和。
for (int i = ; i < total; i++) {
if （currentStoryPonit == null || currentStoryPonit == ） continue;
If （sum + currentStoryPonit > ） continue；
sum += currentStoryPonit；
currentStoryPonit = 下一个故事的故事点。
}
三：剩下的故事按照上述逻辑继续计算最优值。
所以这里支持用户调整故事的顺序（上下排列顺序），commit 后将同步至jira中。
注意点：除故事外的其他问题类型可以预估故事点，并且容器视图将重新计算，但是无法commit。
添加人员后，各个人评分当前冲刺的故事点，如下图所示，新增一个人后，总工作量变成原来的一半。
如下图所示：故事1分配给3个人， 则在工作量统计计划图中，按照分配的人从上到下依次分配满为止。
2、自动化的调度安排机制：
自动调度机制是Jira项目组合的核心功能之一。它计算优化的、现实的资源分配，并据此预测发布日期、资源利用率和瓶颈。
在不进行任何额外计划配置的情况下，调度算法将考虑以下方面：
- 待办事项的优先级
- 版本和冲刺分配
- 预估
- 待办事项之间的依赖关系
- 团队时间表
还可以考虑：
- 团队和个人可用性
- 人的技能
- 有空缺勤
- 工作阶段
- 可配置约束
版本自动分配仅当至少定义了一个具有固定结束日期的发布时才有效。在这种情况下，带有发布分配设置为“Calculate”的待办事项列表项将根据优先级自动放入发布中。
调度算法目前首先优化最高优先级项目的调度。有可能出现这样的情况，即如果团队以较低优先级的问题开始，那么团队可以在发布中容纳更多的容量，但是Jira的Portfolio不会在日程安排中建议这样做。具有最高优先级的项也应该首先启动。
此外，用户可能希望首先将具有最高风险的问题区分优先级，以便在流程早期处理不确定性。
可以通过调度算法静态地分配或自动分配以下字段：
版本 手动：“项目应该随版本X一起交付”；自动：“项目适合哪个版本？”.
团队 手动：“这个故事应该由团队A实现”；自动：“基于技能和能力，哪个团队可以做到最好？”
成员 手册：“成员A/或成员B应该为此工作”；自动：“基于他们的技能和可用性，最好X、Y和Z在这个故事上工作。”
如果在下拉菜单中将字段设置为“Calculate”，那么在下一次重新计算时将自动分配一个值，该字段将得到蓝色背景。
可能影响调度安排的场景：
一个问题被另一个问题所阻塞：依赖关系将影响调度安排。如果问题A被问题B阻塞，问题A将在问题B之后被调度。
问题被分配给版本：如果问题被分配给一个版本，那么问题将在该版本中调度。
问题被分配给sprint：如果问题被分配给sprint，那么问题将在该版本中调度。
团队中的某个成员有这种技能：如果问题必须要有某种技能，并且团队成员中没有一个具有该技能，则根本不会安排该问题。如果团队成员中只有一个具有所需的技能，那么问题将被分配给这个人。
设置阶段：如果已经配置了阶段，那么您的问题将分为与您相同的多个阶段。
计划开始日期的定义：如果计划中有活跃的sprint，那么所有sprint中的最早日期将被选为开始日期。如果您没有活跃的sprint，那么计划发布的最早的固定版本日期将定义计划的最早开始日期。投资组合按顺序查看发布。
我们查看每个项目具有固定开始日期的第一个版本，并选择其中最早的一个。如果没有与前两条规则匹配的sprint或版本，Portfolio使用“today”作为计划开始日期。
3、配置
3.1 Stages and skills：
阶段与技能:阶段是每个工作项顺序执行的活动。另一方面，技能是团队成员必须完成工作项的能力。技能可以在每个阶段定义，并且可以用来对阶段中的不同类型的工作进行分类。建议先创建阶段，后创建技能。
如上图设置两个阶段开发与测试，开发阶段有UI、后端、前端3个技能，测试阶段包括测试技能。设置后，效果图如下，开发阶段占70%，测试阶段占30%。
展开后，各个阶段的技能继续按照比例划分故事点。
接下来演示自动分配团队、成员，如下图，添加成员以及为每个成员设置技能
再到计划中点击重新计算后发现，故事将自动分配给所需的人。
当团队中少了某一项技能，这边把测试技能删除了
则故事将不会自动分配，提示由于可用团队成员无所需技能组合，此事务无法计划。
同时，一个人也可以有多个技能包。这个时候故事也将自动分配，因为故事所需的技能包已经满足了
当故事分配完成后，系统会自动预估所需的冲刺。如下的例子需要2个冲刺才能完成。第一个冲刺等待开发阶段完成，第二个冲刺开始测试阶段。（至于每个人为什么是6个故事点：原因是团队总的故事点有30，团队有5个人评分故事点，每个人6个故事点。）
3.2 Scheduling：
3.2.1、Errors & warnings：定义计划中是否显示错误和警告。这些可能涉及多个问题，例如数据冲突或计划错误配置。
3.2.2 Planning mode
Planning unit：用于估计待办项的单位，有天、小时、故事点等。
Sprint length：冲刺周数
Default velocity：当没有设置速度时，团队的默认速度。
Unestimated item scheduling：当待办项未预估时的处理方式。
- Base on default estimates：基于默认设置的故事点等。
- Base on target dates：未预估项将被预估到所属冲刺、版本的最后的期限，或者是目标期限。
- Off：未预估项会被忽略，并且不会影响Schedule安排。
3.2.3 Dependent story constraint：如果是on，相互依赖的待办项不能同时进行。例如在scrum teams，需要在不同的冲刺中；在kanban teams，需要在不同天中进行。如果是off，可同时进行。无论是哪一项，依赖项必须在前面。
3.2.4 Maximum assignees per story：设置每个故事可分配的最大人数
例如：
目前每个故事可分配的最大人数为3个，团队人员配置如下：
点击计算，可自动分配人员：
现在将最大人数改成2个，重新计算
将报如下错：
原因是2个人不足以瓜分这个故事，所以会报这个错误。现在将团队配置改一个方案，如下
点击重新计算后，
分配正常，只分配2个人即可。
3.2.5 working hours and days
包括设置区域、时区、工作时间（设置每个人每个工作日可用的小时数）、工作周（work week）及设置非工作日（起始日期、结束日期、描述）
3.2.6 Stage sprint constraint：如果设置为on，不同的阶段将按顺序安排到不同的冲刺中。如果是off，多个阶段可安排到同一个冲刺中。
4、多个场景计划（Scenarios）：
该特性允许用户尝试不同的场景。例如，用户拥有具有标准团队速度的场景A，但是可能会出现一些降低团队速度的情况。这时候可以降低场景B中的速度，切换到场景B评估此类风险的影响。
- 各个场景可选择颜色来区别
- 可从一个场景复制出另一个场景；或者创建一个空白场景（不包括修改）
- 各个场景的修改仅对自己有影响
5、团队速度
|
1 |
Team velocity |
|
|
2 |
Forecasted velocity |
预测接下来的速度，基于
|
|
3 |
Past velocity |
|
6、REPORTS
6.1 主题（THEMES）
主题（THEMES）是高层战略重点领域、价值流或投资类别，用于设置优先级和定义团队将把大部分时间花在哪里。
- 主题是用于标记待办事项列表元素，不是面向时间的。
- 主题关注于相对的资源分配，并允许比较在一个主题上花费的资源与另一个主题上的资源。
- 一个故事只能被分配给一个主题，所以如果史诗中的故事被分配给多个主题，那么史诗就被隐式地分配给多个主题。
| Theme field | Description |
|---|---|
| Color |
颜色用于一目了然地区分不同的主题。 |
| Target |
是在每个主题中定义的目标值，用于比较估计和实际情况。目标分配百分比总计将达100%。确保这一点的最简单方法是留至少一个条目空白，然后基于100%减去其他定义的目标值自动计算该值。刚开始创建时，各个主题将平分100%。 |
| Estimate | 求和所有带有该主题的待办项d1，再求和所有待办项d2,最后计算百分比d1/d2 |
| Actual |
实际花在主题上的时间。这个时间计算是基于Jira发布的工作日志的。只有当待办事项列表项具有指向Jira问题的链接时，并且只有当这些问题具有已记录的工作时，才可以使用。即需要与jira关联才会生效。计算逻辑同上。 |
例如：
目前故事计划如下：
故事1被主题“新功能”标记，故事2被主题“技术FOCUS”标记，故事1与故事4已完成。史诗将拥有两个主题，故事只能拥有一个主题。
查看主题报表如下：
新功能：Target：50%，评分100%
Estimate：拥有该主题的未完成的故事点和为0，所以0%
Actual：拥有该主题的已完成的故事点和为3，所有已完成的故事点和4，所以75%
技术FOCUS： Target：50%，评分100%
Estimate：拥有该主题的未完成的故事点和为2，所有未完成的故事点和为3，所以66.7%
Actual：拥有该主题的已完成的故事点和为0，所以0%
No Theam Assigneed同理。
7、关于自动调度算法安排的冲刺个数的分析
自动调度算法根据故事点数、人员分配及可用来确定需要安排的冲刺。
例：
上图中6个故事都已预估了故事点，portfolio根据算法将完成这些故事的冲刺定为3个。团队配置如下：
团队有5个人，冲刺设置的总故事点为10，那么每个人可分到2个故事点。那么故事按照待办事项列表从上到下取，即第一个迭代开始安排故事3、故事2、故事4、故事5、故事1的开发阶段，此阶段的故事点总和5 < song、admin、user1所分配到的故事点总和，所以在第一个迭代安排上述5个故事优先做。而故事6安排不了是因为故事6的开发故事点为1.5，将超过开发人员的能力，所以排到下个迭代。假设将故事6的开发故事点改为1，此时开发人员的承受能力刚好，点击重新计算可得：
此时故事6也安排到迭代一中。
同理，迭代二只能安排前4个故事进行测试。并且注意这里必须是开发阶段完成之后，测试阶段才会开始。如果想要将多阶段的任务排列在同一个冲刺，可按照如下设置：
此时再次计算，查看plan：
可发现多阶段可在同一个冲刺进行。
8、关于团队成员于不同迭代冲刺速度下的工作量分析
成员在团队下的工作量分配比例主要有两个方面的影响：团队速度与工作时长。
例如按照下面的方式设置团队速度：
总故事点为20.9，user1:user2:user3 = 1:1:2,那么根据比例可获得的工作点分别为5.225:5.225:10.45,那么根据portfolio的计算逻辑，“四舍五入”，并且保留一位小数，按照人员从上到下依次计算，得到每个人的工作点为5.2:5.2:10.5，最后一个人将由总量减去前面的人，得到剩余值。
上述是只跨一个冲刺的情况，这边再提供一组数据，让冲刺跨2个。
设置迭代工作总量定为20.9，user1:user2:user3 = 5.225:5.225:10.45，重新calculate得到在第一个冲刺的工作点为：5.2 : 5.2 : 10.5，第二个迭代为5.2 : 5.2 : 10.4，user3在两个迭代为了公平也将进行工作量平衡。
接下来讨论一个用户在不同团队下的工作量：
一个用户可同时在不同的团队里工作，例如ui设计师需要为两个团队出设计，而每个团队都有各自的工作故事点，这时候这个ui设计师的总工作量则是所有参与的团队加和，并且可以无限大。显然这样的方案并不合理。这时候就需要手动调控，即将这个用户在每个团队的工作时长设置合理，当工作量加和时也合理。