把真实世界，真实用户的需求转变成软件工程可以理解并度量的过程。
软件产品设计->用户功能地图->产品演进地图->产品界面设计->开发故事撰写->产品交付计划
产品界面设计
草图设计
低保真的草图可快速制定产品布局、导航、信息结构和功能优先级. 绘制草图 用尽可能低的成本和草图本身的可塑性去激发所有参与者思考并尽快发现问题。发散可能存在的多种解决方案，通过较为具象的方案帮助项目组快速在过程中审视、验证想法
原型设计
中保真线框图或可交互原型没计产品关键页面功能内容、和核心流程。
中保真线框图
将方案进一步具象，丰富产品的页面功能、信息内容、表现方式，逐步清晰产品形态
可交互原型
将线框图进行串联，实现原型的可交互，可点击和可操作，为用户提供了接近最终产品的真实想法
视觉设计
明确产品视觉风格，建立符合功能定位和用户定位的产品设计
开发故事撰写
用户故事是软件开发者对用户需求的描述，也是项目中一个可被跟踪的小单元，它就像占位符一样在协作对话里连接客户和团队。一个故事的完成由客户的成功标准来确定。
故事卡格式：
作为一个[角色]
我想[用户目标]
以此[用户价值]
验收标准
验收标准是指该故事卡所描述的功能实现的同时，需要满足的各种条件，以及极端情况。验收标准可以是多个同时存在，验收标准尽量列举完成无缺漏。
撰写原则 INVEST
INDEPENDE 各自完整，独立于其他用户故事。
NEGOTIABLE 总是可以被替换和重写，直到成为迭代的一部分。
VALUABLE 一定要能对最终用户或商业有价值。
ESTIMABLE 参考其他故事，功能点的大小可以被评估。
SCALABLE 合适的大小，别大到无法计划或实施。
TESTABLE 提供可被验证的必要信息。怎样证明它有用？
范围和优先级制定
（通常是研发经理的工作）
范围和优先级制定:软件工程中有效的项目管理方式，更精细化的项目过程管理
产品交付计划->故事卡工作量评估->优先级判断->迭代计划->沟通计划->项目正式启动
故事卡工作量评估
估算，也叫“评估故事大可以帮助团队更好的对任务排列优先级，做计划以及项目决策。估算过程本身对团队也是有意义的。团队在估算时，会讨论任务的需求细节，这样大家对于需求有了更深入的理解。用相似估算值的故事卡可以在决定项目范围时从迭代中移入或移出。
优先级判断
迭代与发布
从评估过优先级的story开始，把相关的故事归类到大小近似的各个迭代中(充分考虑依赖关系)，然后把迭代纳入到各个具有可度量商业价值的发布中。
沟通计划
沟通计划的目的是为项目交付周期的交流和相互支持提供指导。在敏捷项目里，面对面交流比文档好。但是，除了会议以外，依然会有一些共享工件，比如报告和项目计划。
Who
参与沟通的人是谁，什么角色。
What
需要沟通的信息，或者需要分享的内容。
When
什么时间，或者以什么样的周期频率来沟通。
Why
双方希望的产出物是什么。
How
沟通形式
电话？面对面？视频？邮件？
By who
谁来组织这个会或这次沟通。
