关于敏捷开发中的Sprint Backlog

我个人是比较推崇敏捷开发的，小步快跑，不用考虑太多无关的格式，规则，提倡把任务说清楚，快速开始，快速迭代，项目能很快进入节奏，推进起来。

当然不是所有项目都适合敏捷开发，敏捷开发更适合10人以下的小团队，项目更适合快速试错期的，或者持续跟进迭代的，或者是某个功能模块，某个单一系统这种。

如果是关联性很高的大中型项目，需要涉及部门较多，人员较多，还是传统项目管理模式更适合。

今天计划把最近的一些需求和问题整理到禅道，所以在建产品计划时，想用敏捷管理中的冲刺的形式，Sprint Backlog来记录需求。

那么，Sprint Backlog如何写更好呢？

我搜索了很多关于Sprint Backlog和Product Backlog相关的知识，我想直接看到相关的标准样例，很多都是列表形式，或者卡片形式，也许就应该如此之短才能更敏捷。

但是有一些功能还是需要有详细说明的，所以肯定会需要标题＋详情的模式。

所有好的标题都有共同的特点，如果放在任务列表这个场景下，那么简洁、清晰、便于理解，重点突出，是我觉得重要的几点。

如果需要写详情的Sprint Backlog，格式应该什么样呢，网上很少有特别明确的，那我就总结个适合现在自己的吧。

需要站在用户角度，因为这样更直接，也就是用户故事。

什么样的功能解决什么问题，用户需要什么样的功能，解决什么样的问题。

达到什么样的效果，这样做的目的是什么？有什么商业价值，有什么好处？

最后，如何验证效果，需要特别说明的时候可以写出来，以便测试同学理解。

我个人非常喜欢加备注，tips，提醒这种，有点像研发中的注释，别小看这个地方，很多功能如果涉及关联性和历史问题的，最好写一下提醒下项目组成员。

干货来了，我要试着写一个样例，弥补网上没有这块信息。

标题：希望未发布的文章可以删除

详情：网站小编希望可以删除未发布的文章，以便让文章列表看起来更清爽，同样可以减少冗余数据。

备注：已发布的不可删。举例，这可能显而易见。

这里就不写验证了，因为验证方式很清楚，就是新建一个文章，删掉，看看有什么问题。

自己臆想的一个Sprint Backlog，可能不那么有价值，作为借鉴和参考吧，算是一个简易的模板了。