敏捷 software development teams often use 用户故事 作为表达用户需求的简单明了方式。
理想情况下，将这些用户故事细分为 小 尽可能，同时也尝试 最小化依赖.
但是，自然而然地，当您将“用户故事”细化时，它们变得越来越相互依赖。像软件开发中的大多数事物一样，它’s a balancing act.
尽可能减少用户故事。但是当这样做变得繁重或毫无意义时，就不要再分解它们了。何时可以传递用户故事（ 做完了 ）在不到1天的时间内，我认为将其进一步分解毫无意义。
使用主题的概念将这些相关的用户故事归类在一个标签下，并将它们放在一起。
您可以通过将纸夹在一起将纸牌实际保持在一起。或者，您可以在白板的左侧放置代表主题的卡片，并将所有相关的用户故事与主题一起移动到同一行。
同样重要的是，请尝试确保用户故事之间的任何相互依赖关系都是软依赖关系，而不是硬依赖关系。这样，我的意思是您可能不希望在完成整个主题之前发布任何用户故事。但是，请不要以一种“用户故事”无法做到的方式分解它们’没有别人的工作。
例如，一个‘Login’主题可能包括用于注册，登录和忘记密码的用户故事。尽管这些故事是相关的，并且在某种程度上是相互依赖的，但是它们仍然可以独立交付，并且如果您按正确的顺序进行操作，它们仍然可以从用户的角度进行工作。
您还可以使用主题对您的松散相关项目进行分类 产品积压。例如，在一个网站上，您可能拥有大量与SEO，性能，可用性，重新样式有关的用户故事，或由多个用户故事组成的部分。
在产品待办事项列表中为用户故事分配主题可以帮助您查看新兴的主题，而这些主题可能包含您可能没有注意到的宽松的用户故事。当您看到下一两个Sprint的新兴主题时，这有助于使团队和企业更加清楚Sprint目标。
这是一件有用的事情。它为您提供了有关Sprint的更多信息。它’实际上是关于某事的*，而不是随机收集的高价值但无关的故事。它可以告诉你你’例如，将您的Sprint的很大一部分集中在功能x和y上，例如，在宏级别上，您的优先级实际上在其他地方。
当自上而下设置优先级时，它也有帮助。例如，让’s说，我们做出商业决策，即在接下来的sprint中，SEO将是重中之重。您可以使用SEO主题快速获取所有“用户故事”，并为其赋予优先级。
当然啦’冲刺包括不属于整体主题的项目是很好的。主题只是重点的主要领域，而不一定是重点的唯一领域。
有时，敏捷软件开发存在一种危险，即一切都被破坏了，因此 小而增量 一切都变得太战术化了，或者没有方向，或者至少没有方向。
It’保持较高级别的发布计划或产品路线图很重要，因此Sprint确实将产品推向特定的方向，以便团队可以了解该方向。因为 没有Sprint是孤岛！
您还可以使用主题作为在产品路线图上勾勒出广泛优先事项的简单方法，以显示随着时间的推移重点关注的关键领域。
凯莉
摄影者 *光三斯坦
