用例图通过描述角色用户与系统的交互，来描述系统的功能。很多软件开发团队往往用UML工具或者Word文档等方式使用用例图进行系统的功能设计（概要设计），然后移交给开发团队去具体实现。而用户故事从表面来看仅仅是卡片上的一句话。其实

Ron Jeffries的三C最能说明用户故事的玄机。

第一个C代表卡片(Card)。用户的需求是卡片上的一句话（“作为。。。我能。。。因此。。。”）。尽管只有简单的一句话，其实卡片背后隐含的玄机是“每个卡片代表一个要解决的问题，而不是一个功能设计实现”（当然还有很多人把很详细的需求写到了纸片上，其实他们还没有真正理解用户故事的意义）。很多软件项目的失败就是因为团队过早关注具体实现（功能实现与技术实现），还没有明白客户的真正问题是什么，就过早地进入功能设计，提出方案，从而导致设计出的系统不能满足客户的需要，扩展性不够。因此用户故事卡片其实反映了是精益思想中的推迟决定(Delaying Decisions)的思想，只有真正着手实现的时候，才开始细化，设计具体方案。

第二个C代表沟通(Communication)。用户故事卡片并不是需求，仅仅是一个Placeholder，真正的需求是在团队准备着手开发这个故事时，团队集体设计的结果。敏捷开发鼓励使用有效的沟通方式（面对面+白板），需求往往是在坐在一起的团队成员（产品负责人、开发人员、测试人员）一起参与设计，确定合适的方案，但是具体的建模方式可以是UML，可以是Word文档，也可以是白板上的图，关键是保持信息的及时有效。多数敏捷过程中都提倡使用并行开发（也就是需求，开发以及测试是同时进行，不停的向前演进）。对于一个卡片上要解决的用户问题，一般都可以有多种方案，软件团队能够在很大程度在多种功能实现方案之间权衡，使得系统能够更好的符合用户的需求，真正对客户有价值。但是设计用例往往将用例画到UML工具或者Word文档中，而且这个往往是由商务分析师负责，其他的团队成员只是参与角色。分析师做出用例之后移交给开发团队，其实是一种小的串行模式，大大加长了反馈的时间。尽管软件团队也可以用用例方式来涉及多个方案，但其实是一些小的串行开发，经济成本以及时间成本比并行开发要高不少。

第三个C代表确认(Confirmation)。这其实就是用户故事的验收条件。在敏捷团队中，测试人员以及产品负责人往往把用户故事写成客户测试(Customer Test)，变成可运行的需求。因为用户故事是一个开放性的客户问题，因此需要定义一个结束条件，也就是验收标准，Confirmation其实就是起了这个作用。

总之我认为用户故事管理软件需求最大的好处就是：