Azure DevOps大量工作项Stack Rank自动变更，原因待查求助

以下是针对你遇到的“仅修改2个工作项状态却导致20+项Stack Rank变更”问题的核心原因分析及验证方法：

• 看板自动排序规则触发批量更新
  Azure DevOps看板默认可能开启了基于状态的自动排序逻辑（比如Done列的工作项会被自动置于列尾，当你将项从Doing改到Done再改回Doing时，系统会将其重新插入Doing列的指定位置）。为了维持看板列内的排序一致性，系统会批量调整同列所有工作项的Stack Rank，而非仅修改目标项。
  验证方式：进入看板设置查看「卡片排序」选项，确认是否启用了自动排序；查看受影响工作项的历史记录，若Stack Rank变更的操作人为「System」，则可确认是系统自动触发的排序调整。

• 关联工作项的层级/依赖联动
  若你修改的2个工作项存在父项、子项，或与其他20+项有前置/后置依赖链接，在状态变更时，系统会自动调整这些关联项的Stack Rank以保持层级结构的排序连贯性（常见于Agile/Scrum模板项目）。
  验证方式：检查目标工作项的「链接」标签，确认是否与受影响项存在层级或依赖关系；对比受影响项的变更时间与目标项的修改时间是否完全同步。

• Stack Rank全局数值重排机制
  Azure DevOps的Stack Rank是全局唯一的递增数值，当系统需要为修改状态的工作项重新分配合适的Stack Rank（比如从Done改回Doing时需要插入到Doing列的数值区间），会触发同区域（同一迭代、区域路径）内其他工作项的数值批量调整，避免数值冲突。
  验证方式：对比受影响项变更前后的Stack Rank数值，若呈现连续的增减（如原100、101、102变为99、100、101），则符合该机制特征；确认受影响项是否都归属同一迭代或区域路径。

解决建议 #

• 若为看板自动排序导致，可在看板设置中切换为「手动排序」，或缩小自动排序的应用范围；
• 若为关联项联动，可梳理工作项的链接关系，移除不必要的层级/依赖，或调整状态变更的操作逻辑；
• 如需精准追踪触发源，可前往组织设置的「审计日志」，查看所有工作项变更的触发事件、操作人及关联上下文。

内容的提问来源于stack exchange，提问作者Charlie