这本书从非常实践的角度，以个人实际工作出发做了很好的总结和领会，分别从怎样编写产品Backlog、怎样准备Sprint计划、怎么制定Sprint计划、怎么让别人了解我们的sprint、怎么编写Sprint Backlog、怎样进行每日例会、怎样进行Sprint演示、怎么做Sprint回顾、怎么制定发布计划、怎么做测试等方面进行了讲述。对于初入敏捷的人员来讲是一本很好的参考书，语言简练、易懂，不像官方书籍那么晦涩难懂，是一本很好的指导性实践书籍。但如果你只是为了通过考试，其实这本书的参考价值并不大。

怎样编写产品 backlog

以很好的示例讲述了Story或者backlog条目的编写方式，大体由如下字段组成：

ID

Name（名称）

Importance（重要性），例如10 或 150，分数越高越重要。

Initial estimate（初始估算），最小的单位是故事点（story point），一般相当于一个人天。

How to demo（如何做演示）

Notes（注解）

有时为了便于产品负责人判断优先级别，我们也会在产品 backlog中使用一些其它字段。比如：Track（类别）、Components（组件）、Requestor（请求者）、Bug tracking ID（Bug 跟踪 ID）等。

指出如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。

怎样准备和制定 sprint 计划

在sprint计划会议之前，要确保产品backlog的井然有序。

1.   Backlog必须存在

2.   只能有一个backlog和一个po

3.   所有重要的backlog都已经根据重要性被评过分

4.   Po应当理解每个故事的含义

Sprint 计划会议会产生一些实实在在的成果：

1. sprint 目标。

2.  团队成员名单（以及他们的投入程度，如果不是 100%的 话）。

3.  sprint backlog（即 sprint 中包括的故事列表）。

4.  确定好 sprint 演示日期。

5. 确定好时间地点，供举行每日scrum 会议。

产品负责人必须参加

每个故事都含有三个变量：Scope, Importance, Estimate（估算），前两个po负责，Estimate团队负责。

从用户感知的角度，质量可以分为内部质量和外部质量。

所有重要性高的backlog条目都要填写“如何演示”

Sprint目标可以很宽泛

Po可以通过更改故事优先级、缩小故事范围、拆分故事等方法调整放入sprint backlog里的故事。

团队可以通过本能反应、生产率计算两种方式来决定把哪些故事放到sprint里面。

这里提到了计划纸牌估算和（Yesterday’s weather）。

故事索引卡和任务即时贴

More important                         less important

故事是可以交付的东西，是po所关心的，任务是不可交付的东西，po对他不感兴趣

对于“技术故事”：

1.  尽量避免技术故事，将其转换成普通故事

2.  或者把他当作某一故事的任务

3.  如果以上都不行，就存放在一个单独的列表

Bug跟踪系统（Jira）   VS  产品backlog

Issue与故事的对应

为了让别人了解团队的sprint，可以做Sprint信息页：

怎么让别人了解我们的sprint，这是一个与干系人进行沟通的方式与方法，确保相关干系人及时知晓项目情况。

怎么编写Sprint Backlog

在sprint计划会议之后，第一个站会之前完成创建sprint backlog（这里是指实体的）

需重点关注燃尽图怎么发挥作用。

还提到了怎样布置团队房间，在大部分单位这是个伪命题，但我们可以力争去做到更好的沟通、更好的站会环境。特别重要的是让团队坐在一起。

那么怎么进行每日站会、做好Sprint演示及回顾呢？作者没有做太多的解释，需要的是规则和执行，并在不断的实践中去完善，作者提到了一些技巧，在实际工作中可以去参照。

在组合使用Scrum和XP这章中，作者提到Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践，XP的核心是结对编程和TDD

我们需要知道TDD，第一个任务是编写一个失败的测试，最后一个任务是重构

如果感兴趣的话可以进一步了解多团队的管理方式，作者从实践的角度也进行了讲解，但不够系统化，需要根据方法论进行进一步的学习。