用户故事：卡片、对话和确定；基于三个步骤进行开展。
举例：项目：A公司是一家检测设备公司下的子公司，主要服务对象是制造业，由于早起软件系统陈旧，导致客户满意度很低。公司决定，面向制造业的痛点，重新开发一款迎合当下市场的软件，应包含：企业基础架构、生产作业管理、生产质量管理、生产过程监控、能耗管理等等，需要在3个月内上线。幸运的是，客户愿意指派对接人员与研发人员一起规划系统。
在某周的早上，客户、产品负责人、研发小组、Scrum教练在一个单独的环境中，展开对系统需求的研讨和系统功能的确定。
识别客户：
1.每人面前摆放一堆空白卡片，接下来，所有成员开始绞尽脑汁在卡片上书写用户角色卡片：
- BOSS
- 厂长
- 线长
- qc
- 一线员工
- 巡检员
- 品质负责人
- 组装工
- .....
2.直到所有人无法再想起其他角色，下一步将所有用户角色卡片进行汇总，去除相同的角色，过程略......
又过了许久.......
角色确定为：
- BOSS
- 厂长
- 线长
- qc
- 一线员工
- ......
角色建模：接下来，团队考虑为每个角色卡上添加详细描述。详细描述将根据领域和软件类型的不同而有所不同，需要考虑一下因素：
- 用户使用软件的频率；
- 用户在这个专业领域的专业水平；
- 用户对电脑和软件熟悉程度；
- 用户对正在开发的软件的熟练程度；
- 用户使用软件的真正目的。
- ........
基于上面的团队对每个角色卡片讨论，他们觉得有必要更新一下用户角色卡片：
- BOSS：关注年、季度、月生产计划达成率、品质数据，很少使用系统，主要通过图标来观察厂区的生产状况；
- 厂长：关注年、季度、月生产计划的达成进度及质量，经常使用系统，主要关注生产计划合理性、供应商来料情况、来料质量、订单、即使生产状况及品质信息；
- 线长：经常使用系统，关注点：根据排产单进行投产、防止组员偷奸耍滑，确保生产过程数量质量可控；
- qc：经常使用系统，关注点：确保在制品的品质和已完成的产品质量，找出原因并上报；
- 一线员工：不登录系统，通过SOP来确定当前操作是否正确，关注工时；
有了上述的用户角色卡片及延展性的备注后，Scrum教练向组员建议创建用户画像，并解释用户画像可以使用户角色更丰满立体，不再是冰冷的需求代号，而是真实存在。
于是，厂长叶海龙这一画像，就这样诞生了：（基于真实存在的人员）
通过这张画像，是否对系统某一个用户的形象更为具体？组员是否更清晰产品所要面向的具体使用者，那么系统功能就会相对清晰明了，避免了基于客户/研发人员头脑中”理所当然的需求“；
有了这些最初的故事列表，团队进入下一个步骤”编写故事作坊“，于是成员又开始进行一次头脑风暴：
第一种方式：
- 用户不能注册系统，需要管理员在系统进行配置；
- 管理员给用户设置角色，不同角色在系统中拥有不同的角色权限；
- 用户可以看到产线实时生产数量；
- 用户可以打卡上岗；
- 根据不同的产品条码，RFID自动识别，系统自动播放sop;
- 不良品禁止流向下一个工位；
- 来料需要检测；
- 设备需要点检；
- 可以制定生产计划；
- 可以对接考勤系统；
- 检测模板可以上传到系统中;
- 可以编写生产计划；
- 生产实时看板
- ......
第二种方式：
叶海龙：
- 可以检查排产是否合理，由系统根据每条线的产量进行自动计算；
- 可以看到产线实时的生产数量；
- 可以查看某个供应商的来料汇总信息，已决定是否验收付款签字；
- ......
- 结束
直到组员无法再写出新的故事卡，然后将所有故事卡进行汇总，除去重复的，组员终于可以松一口气，喝杯咖啡。别高兴的太早，活还没有干完。接下来要做什么呢？各位思考一下....
总结：
1.宏观 – 构建具象认知，构建战略、战术方向:为了让团队在核心用户上达成统一且具象的认知，方便在后续投入上有的放矢；根据用户画像的信息做产品设计，必须要清楚知道用户长什么样子，有什么行为特征和属性，这样才能为产品提出战略和战术层面的指导。
2.宏观 – 探索用户足迹，用户(市场 )导向:详细了解我们的真实用户是如何和产品及其相关内容进行互动等；必须从业务场景出发，解决实际的业务问题，之所以进行用户画像要么是获取新用户，或者是提升用户体验，或者是挽回流失用户等，并最终为用户设计产品。
3.微观 – 构建底层数据基础，如第二条所讲，可以让产品更符合使用的真实需求，从而搞好的贴合客户；一切只为客户满意度，否季度KPI又泡汤了。
2.4微观 – 方便信息的处理:有了标签后组员可以方便地处理各个量化需求并进行分类，评估迭代周期。