本书讲的都是scrum实战的内容，2008年写的，是比较老了，不过还是有很多可以借鉴的地方，作者Henrik Kniberg。
Scrum的两位创始人之一Jeff Sutherland给本书写了序。Sutherland曾是一个风险投资团队的敏捷教练，曾建议是只给敏捷实践实施情况良好的敏捷公司投资。看来他对推自己的Scrum框架是非常骄傲的。许多介绍敏捷的文章、书籍包括像敏捷指南都是描述了为什么要做敏捷，敏捷是什么，而真正对于一个准备实行敏捷的团队来说难点在于如何落地。本书就很详细的描述了如何落地Scrum的具体步骤。
本书不同章节包括如何编写backlog、准备sprint计划、制定sprint计划、让别人了解sprint、编写sprint backlog甚至具体到如何布置团队房间、如何进行每日例会都详细介绍了。
书中第三章如何准备sprint计划写的非常详细，里面有些观点很有意思
内部质量和外部质量
作者把质量分成了内部质量和外部质量
• 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
• 内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
对于用户来说只能感受到外部质量的好坏，但如何内部质量没有处理好肯定会表示成外部质量的问题。牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。但内部质量怎么管理呢？有些提高内部质量的工作能不能提现到sprint里？作者提出一个观点很有意思即将内部质量外部化。确实将设计一致性、提高代码可读性等化成可以提现工作量的user story，这才体现出做为一个scrum master的价值
sprint 要包含的故事
一个sprint里要放多少故事呢？这是实战中肯定会碰到的问题，作者给出了两个答案一个是本能反应，一个是生产率计算。
本能反应-这也算答案？细细想想，太棒了就应该是这样，做为一个自组织的scrum团队大家都是有经验的，遇到评估自己的工作量，最直接的就是按自己原来处理内容的工作来对照评估，这样也是成本最低，最容易做的。不准确怎么办？没有关系啊，scrum本来就是一个迭代一个迭代的，在下一个迭代重新调整就可以了。而且之前sprint工作量就成了以后sprint工作量评估的基准，这就引出了第二个答案基于生产率的计算，这就是用已完成工作总量做为一个衡量方式。第一步先得出现有的生产率，第二步计算在不超出估算生产率的情况下可以加入多少故事。
技术故事
在scrum的框架里介绍了需求要通过用户故事user story的方式来提现，但在实际开发中都知道往往有些工作不好提现在一个user story里或者不发提现出直接的用户价值，那这种工作怎么处理呢？作者给出了答案-技术故事，或者叫做非功能性条目需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值
如：安装持续构建服务器；编写系统设计概览；重构 DAO 层；升级 Jira等。
技术故事常常会因为某种原因给设置一个低优先级,但产品负责人往往不能对此做出正确的权衡，该怎么做了，作者给出了三种方法
- 把技术故事变成可以衡量业务价值的普通故事
- 看看这项工作能不能当作另一个故事中的某个任务
- 定义为一个技术故事，用另外一个单独的列表来存放。产品负责人能看到它
准备好sprint其实是执行成功的scrum项目管理很关键的一步，上面这几点在实际sprint迭代过程中确实会遇到，可以借鉴。后面几章有些点也很有启发，比如作者专门有一章就是讲如何让别人了解我们的sprint, 我们要让整个公司了解我们在做些什么。仔细想想确实这才体现了scrum三大支柱之一的透明。但要真正实现好，也需要有整个公司的支持，这就需要更高一级也有敏捷的思维了。
其他内容我觉得还是要有所取舍，比如作者专门有一章介绍如何布置团队，可能就要根据自己团队的现实条件决定。还有的比如“处理’我不知道今天干什么‘的情况”,感觉不太靠谱。
当然尽信书不如无书，既然本书都是实战的内容，那就必须放到实战中去检验，特别这位作者是瑞典人，团队也是国外的团队，所以可以在团队中去大胆尝试，然后根据反馈来调整，这也正符合scrum的价值观吧。
