一位敏捷项目经理希望将需求文档转换为史诗（epics）、能力（capabilities）、特性（features）和用户故事（stories）。项目经理应该估算多少个迭代的用户故事持续时间？

在敏捷实践中，用户故事通常被设计为在一个迭代（Sprint）内完成。这是为了保持迭代的短周期和交付可工作增量的原则。将用户故事分解到足够小，使其可以在一个迭代中估算和完成，有助于团队更好地规划工作，更快地获得反馈，并适应变化。如果一个用户故事需要超过一个迭代才能完成，它通常会被进一步分解成更小的用户故事，或者被视为一个特性（feature）或史诗（epic）的一部分，这些更大的工作项才可能跨越多个迭代。因此，估算用户故事的持续时间时，目标是将其限制在一个迭代内。