只从一个角度写用户故事，往往容易忽略一些需求，因为有些故事针对的并不是系统的一般用户，因此需要采用一些初始步骤来更好的编写故事。
用户角色建模
1 通过头脑风暴，列出初始的用户角色集合
每个人尽量想出多的角色，并把它们写在卡片上；不需要对角色进行讨论和评估；直至很难再想到新的角色为止。
2 整理最初的角色集合
分析角色的相似，重叠之处
3 整合角色
整合和弄色角色，将重叠较大的角色，整合为一个角色；重叠较小或有必要分开的角色保留。
4 提炼角色
根据整合好的角色进行讨论，通过给每个角色定义一些特征来建立角色模型。角色特征是关于同属于这一类用户的事实或信息。任何可以区分这个角色的信息都可以用作该角色的特征。
适用于任何角色建模的角色特征包括：
- 用户使用软件的频率
- 用户在相关领域的知识水平
- 用户使用计算机和软件的总体水平
- 用户对当前正在开发的软件的熟悉程度
- 用户使用该软件的总体目标
此外，还可以使用虚构人物和极端人物来对角色进行补充。
搜集故事
拖网（Trawling）式需求收集
1 用不同大小的网用来捕获不同大小的需求。可以先捕获大的需求，以便形成对软件的整体感觉；然后捕获中等大小的需求，暂时不理会小需求。大小可以是需求的商业价值高低或必要性程度。
2 拖网捕获可能会漏掉需求，因为这个需求目前对系统来说并不重要。而随着每轮迭代的反馈，有些需求可能会越来越重要，而有些曾经重要的需求，重要性可能会降低甚至变得不需要。
3 我们不可能一次捕获所有的需求，可有可能会捕获到不必要的需求，他们会使需求膨胀。
4 需求收集技能也是发现需求的一个要素。
需求捕获方式
1 辨别传功规范过程和敏捷过程最简单的方法之一，是看他们搜集需求的方式。传统规范过程的特征是过分强调在项目早期正确的获取并写出所有需求。敏捷项目承认没有一种理想的方法，可以在一个单一阶段获取所有的用户故事。敏捷过程也承认用户故事有一个时间维度：随着时间的推移以及先前迭代中加入产品的故事，一个故事的相关性会有所变化。
2 即使承认无法为一个项目编写所有的故事，我们还是应该在早期尝试编写我们可以编写的故事，即使许多故事还只能停留在十分笼统的阶段。使用故事的好处之一是我们可以用不同的详尽程度来编写，我们可以展望一个发布的时间，故事的发布时间越往后，故事可以约粗略。
创建故事的方法
- 用户访谈 -- 尽量使用开放性问题
- 问卷调查 -- 适用获取具体问题的回答
- 观察 -- 有助于获取真正的需求
- 故事编写工坊 -- 由开发人员，用户，客户等共同参与的会议；只编写尽可能多的故事，不进行优先级排序；从角色和主页面开始，推荐使用深度优先的方法，收集完整个操作流程中的所有故事，然后换下一个角色。故事编写工坊的目的是在短时间内写出更多的故事。