“可工作的软件胜于全面的文档”。
这句话是敏捷宣言中的四大价值之一，也说明了对于每一个Sprint而言，交付一个可工作的软件非常重要。但是在短短的一个Sprint当中很难交付一个完整的应用，所以应当做到“潜在可交付”，潜在可交付有如下特征
- 潜在可交付意味着测试过。测试过指的是经过测试，且不存在重大的问题。
- 潜在可交付并不意味着系统功能的完整。有可能只是实现了一部分的功能特性，但是这部分功能特性是需要我们测试过的，且可运行。
- 潜在可交付意味着集成已做好。这里的集成指的是来源于不同人不同团队的代码之间的集成。例如程序员A写的代码和程序员B写的代码组合在一起才能实现一个“潜在可交付”，那么这两份代码必须继承做好。
在每一个Sprint中都要提供一些“有价值”的东西，这里的有价值指的是对客户有价值，即客户可用的功能。这里所说的客户不代表终端客户，有可能是你所服务的“客户”。比如在我们团队中BP小组做的东西的客户可以是Integration小组。
另外一个关于Sprint的最佳体验是，在当前Sprint中抽出一定的精力为下个Sprint做好准备。而在一个Sprint中只塞入能够完成的任务量。
在一个大的团队当中，各个小团队之间应随时保持深度协作，最好不要出现产品从一个团队交到另一个团队手里，又依次传递下去的情况。这样的传递不光在团队之间需要避免，也需要避免在不同Sprint之间进行传递，也就是说不要出现“特定活动的Sprint”。特定活动的Sprint指的是某个Sprint专门做分析，下个Sprint专门做开发，再下个Sprint专门做测试，这样的体验很不好。
作为UX，自己的设计工作有点时候很难和项目其他成员的工作很好的协作。原因是传统项目中习惯将用户体验设计UI设计全部完成再开始工作。UX的设计工作是应该提前，但是也可以尽量切分成一个个小的模块进行设计。这需要很多的经验。
对于Sprint的时间性应保持绝对严格，一个Sprint的长度必须要固定，且不能出现延长。
