我们刚刚开始一个包含许多子项目的非常大的项目。我们目前不使用任何类型的命名流程，但我希望通过后门获得某种敏捷/类似 scrum 的流程。
我将最关注的领域是整个项目的积压工作，至少在我的脑海中，迭代的想法是从积压工作中提取一些东西，更详细地研究并开发到合理的截止日期.
我想知道人们使用什么技术将项目分解为待办事项，以及一旦创建了待办事项，它是如何维护和排序的。以及如何维护元素之间的关系（即必须在可以这样做之前完成，或者这是一个故事现在是五个故事）
我不确定我期望这个问题的答案是什么样的。我认为最有帮助的是，如果有一个开源项目以某种方式保持其积压在线，以便我可以看到其他人是如何做到的。
其他可以从我那里得到+1的东西是来自真实项目的真实用户故事的例子（“用户可以登录”的故事并不能帮助我描绘我的项目中的事物。
谢谢。
我建议您在采用工具之前仔细考虑，特别是因为听起来您的过程一开始可能会在您找到自己的脚时变得流畅。我的感觉是，在这个阶段，一个工具可能更可能约束你而不是赋予你，你会发现它无法替代物理空间中的一个好的卡片墙。我建议你把精力集中在手头的任务上，当你觉得你真的需要一个工具时，就去拿一个工具。到那个阶段，您将更有可能清楚地了解您的要求。
我现在已经运行了几个敏捷项目，我们从来不需要比电子表格更复杂的工具，而且在一个预算超过一百万英镑的项目上。大多数情况下，我们发现白板和索引卡（每个用户故事一张）就足够了。
在确定您的故事时，请确保您始终以对用户有意义的方式来表达它们 - 一些（也许只是很小的）表面功能。永远不要让自己陷入无法向用户展示的有关技术细节的故事。
安排故事的技巧是首先尝试优先考虑您最不了解的事情（计划您想学习的内容，而不是您想做的事情），同时从允许您开发核心功能的故事开始您的应用程序，使用后续故事将功能（和技术复杂性）包装在它们周围。
如果您有信心可以将其中的一部分留到以后，请不要费力地了解其中的细节 - 只需写一张故事卡，代表您稍后需要进行的重要对话，然后得到继续更重要的事情。如果您需要了解即将发生的事情的规模，请查看称为计划扑克的宽带德尔福估计技术。
Mike Cohn 的书籍，尤其是敏捷估算和规划，将在这个阶段为您提供很多帮助，并为您提供一些有用的技术。
祝你好运！
与 DanielHonig 一样，我们也使用 RallyDev（小规模），听起来它可能是一个有用的系统，至少可以让您进行调查。
此外，一本关于用户故事开发方法的好书是Mike Cohn的《用户故事应用》。如果你还没有，我当然会推荐阅读它。它应该回答你的很多问题。
我不确定这是否是您正在寻找的，但它可能仍然有帮助。来自codequeeze 的Max Pool 有一段视频解释了他的“敏捷墙”。看到他的过程很酷，即使它可能不一定与您的问题有关：
所以这里有一些提示： 我们使用 RallyDev。
我们创建了我们的需求所在的包的视图。大型故事被标记为史诗，并被放入它们所针对的版本的发布积压中。儿童故事被添加到史诗中。我们发现最好保持故事的细化。粗粒度的故事使真实地估计和执行故事变得困难。
所以总的来说：
按发布组织
将迭代保持在 2-4 周之间
产品负责人和项目经理将故事添加到发布待办事项中
这是我们过去 4 个月一直在做的事情，并且发现它运作良好。保持故事的大小和粒度非常重要。
记住评估用户故事的 Invest 和 Smart 首字母缩略词，一个好的故事应该是： I - 独立 N - 可协商 V - 有价值 E - 可估计 S - 小 T - 可测试
聪明的：
S - 具体 M - 可测量 A - 可实现 R - 相关 T - 时间盒
我会首先说保持简单.. 使用带有跟踪（和备份）的共享电子表格。如果您发现扩展或同步问题使得将积压工作保持在一致状态变得越来越耗时，请进行交易。这将自动验证支出/再培训成本并证明其合理性。
这是我对类似问题的回答，可能会给您一些想法
很多这些回复都是关于使用工具的建议。然而，现实情况是，您的流程将比您用于实施流程的工具重要得多。远离那些试图把方法论塞进喉咙的工具。但是，也要警惕使用新工具简单地实现旧的非敏捷流程。以下是在确定流程工具时需要考虑的一些重要事实：
综上所述，这里有一些指导方针可以帮助您：
对于较大的组织，如果您使用 SCRUM，请使用级联站立机制。Scrum 主管与他们的团队会面。然后 Scrum Master 以 6 到 9 人的方式开会，由 Super-Scrum-MAster 负责将 Scum-Master 的 scrum 中的项目报告到下一个级别……等等。
您可能会发现，每周举行一次超级 Scrum 会议在您的最高层级就足够了。