今天在大学里我们有一个 Scrum 练习练习（模拟创建软件解决方案的整个过程），我想出了一个不太理解的问题。
假设我们已经定义了我们的故事并给它们一个适当的优先级。还有一个故事没有什么优先级……也许会在最后的冲刺中完成。
问题是，如果这个故事给我们的解决方案设计带来了巨大的架构变化怎么办？例如，从独立应用程序中，您将不得不选择客户端-服务器架构，仅因为这个故事。
在我看来：以某种方式标记哪些故事肯定会完成（在某个特定的时间），那些是关键的要完成的故事不是很自然，但它并不重要，所以团队有他们牢记并做出更好的决定来设计他的解决方案。或者你是如何处理这个问题的？如果有问题。
提前致谢！请原谅我可能很蹩脚的问题。
在现实世界中，$$$ 上线，优先级较低的事情可能永远不会完成。如果他们有一个高风险因素，这在现实世界中意味着更多的风险和低优先级，他们肯定不会完成。在您的情况下，如果您知道它肯定会完成，那么在您的设计会议中，只需确保您的设计能够轻松适应所需的更改，并且在当前故事上尽可能少地付出努力。
因为你说：
在最后的冲刺中完成，也许。
我倾向于同意模糊棒棒糖（和我+1）。
但是，如果您知道必须完成某些事情，但它被放置在最后，那么如果它可能会对架构产生重大影响，那么它只是在错误的位置。
您可以将任务拆分为分析和实施，尽早进行（影响）分析以确定是否真的会有架构影响，然后根据分析结果适当安排实施。
问题是，如果这个故事给我们的解决方案带来了巨大的架构变化怎么办？例如，从独立应用程序中，您将不得不转到客户端-服务器架构，仅因为这个故事。
我不认为您的示例是现实的，这样的功能必须以某种方式成为产品愿景的一部分，您无法在最后一个不太重要的故事中发现这样的变化，必须在最后一个 sprint 之前的某个时间点将其考虑在内最后一个故事。换句话说，我同意@fuzzy 和@Eric 的观点：
这似乎是最后一个负责任的时刻问题。
如果参与的每个人都肯定这是一个要求，并且会影响架构，那么将其放在最后一个 sprint 中是不明智的。
更可能的情况是它可能是必需的。如果您调整您的设计以尽早适应它，您将通过多个冲刺来维持这种复杂性，以支持可能永远不会添加的功能。（业务需求发生变化。）
使用灵活的解耦设计（例如通过TDD演变的设计），可以保持随时间变化的成本相对平稳。
如果必须完成并且将涉及大量架构更改，那么它可能不应该是低优先级。
我唯一能看到它应该被归类为低优先级的情况是，是否可以完全放弃它，或者推迟它是否可以接受，即使它会花费更多（比如产品需要完成并走出家门，以便以后有更多的资金用于它）
虽然优先级主要是客户需求的函数，但情况并非完全如此。可能有一些技术方面是团队确定必须更早完成的项目。例如，选择 ORM 可能对客户来说意义不大，但从团队的角度来看，它可能是一个重要的设计决策。
在我目前涉及 CMS 的项目中，这些事情已经出现过几次，其中必须尽早解决诸如国际化之类的问题，但这不一定是明智之举，因为后来会有一些变化，例如引入另一家公司的软件来处理一些问题翻译可能会影响我们的一些代码。
编辑：技术债务象限也可能有助于调查这类风险，看看如果最终故意让债务受到重创，你可能会遇到什么。