对于多数产品待办事项列表（product backlog）项，尤其是产品功能类，敏捷团队通常使用用户故事（user story）来表达预期的商业价值。
用户故事（user story）的格式通常如下：
简洁的格式可以帮助团队完成较好的用户故事（user story）：容易让业务和技术人员准确理解。然而，有时候团队分配给用户角色的目标和利益，并不符合用户角色真实期望的需求和愿望。乍一看，这些用户故事（user story）写的很好，当从特定用户角色的角度去看时，发现并不正确。 我自己的一个例子。几年前，我带领的一个用户故事（user story）写作研讨会，主题是为某公司建立一个电子邮件系统。这个系统比较特别，它将会被大型电信运营商（如 AT&T和Verizon）授权使用。当时的想法是，当人们从AT&T和Verizon购买一部手机时，他们会从运营商那获得一个免费的邮箱帐户。
研讨会上，一个团队创建的用户故事（user story）如下：
当我看到这个用户故事（user story）时，我的第一感受是，“作为一名手机用户，我不希望在我的邮件信息中看到任何广告。” 这个团队感到困惑。“你是怎么理解的？”，他们问，“这个用户故事（user story）的核心是—我们必须把广告放进电子邮件中，才能让运营商为用户提供免费的电子邮件帐户” 我回答说，“我知道。但是，这样的用户故事（user story）是行不通的，因为从手机用户角度来说，它毫无意义。”
我写了一个新的卡片给了那个团队，“这样的用户故事（user story），才能真正准确地反应手机用户的想法”，如下：
在每个人读过卡片之后，我补充道“你之前写的用户故事（user story）从用户角度来看是没有意义的！手机用户不希望广告出现在他们的邮件中（谁也不希望广告出现在他们的邮件中！）。这样的用户故事（user story）是不合常理的。” 然后我建议他们从手机用户的角度重写一个真正对用户有价值的用户故事（user story）。
这个故事大体如下：
现在这个故事才是有意义的！用户故事（user story）中的用户角色必须是能真正得到这个故事中所描述的价值的角色。这样的角色才符合要求。 当你在写用户故事（user story）时，请停下来仔细考虑一下使用你描述的具体功能的用户角色是谁。是你的客户还是你的客户的客户？公司开发的邮件系统的客户是电信运营商（AT&T 和 Verizon）。他们客户的客户是手机用户。两者都有可能是用户角色，所以需要故事能反映正确的用户角色的需求。 如果你的待办事项列表中存在目标和角色不匹配的故事，可能你需要重写这些用户故事（user story）了。
【本文由“软动力”发布，2017年06月04日】