1. 故事点问题
我们团队的故事卡片缺少重要性和故事点，缺乏数据的沉淀无法度量生产率。需要对故事点做后期统计。
故事的演示等同于wiki里的需求故事里的验收标准。用于设计开发人员更加清楚故事细节。
让产品backlog停留在业务层次上。
计划卡片做故事点估算。
0=“这个故事已经完成了”或者“这个故事几分钟搞定”
？=“我没想法”
咖啡杯=“我太累了，先歇会。”
当故事点数太大则需要拆分成更小的故事。
故事的大小在2-8人天。
2. Sprint计划会
产品backlog对应我们团队confluence的02需求模块，但由于我们没有对故事进行重要性打分，所以并没有做sprint计划会，但我们做了故事地图全景的需求梳理会议，该次会议上基本确定MVP，并将其作为第一个迭代的sprint backlog；然后还在confluence建立了迭代日历。后面的迭代中也将需求梳理会作为一个探针，在前一个迭代的第二周周一举行，由产品经理（产品负责人，业务），开发共同确定下一个迭代的故事列表（sprint backlog）。
3．质量与范围
牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。团队共勉。
如何能不降低质量，缩小范围。减少这个迭代的故事数量，优先级低的故事放到以后再实现。
4．时间盒
时间盒原则控制会议长度，提升会议效率。
5．产品backlog到sprintbacklog
从产品backlog到sprint backlog，要结合团队的生产率，投入和故事点数，由团队决定。Sprint backlog是产品backlog中的一个故事快照。它表示团队在这个sprint中承诺要完成的故事。
6．索引卡的好处
大家站起来四处走动=>他们可以更长时间地保持清醒，并留心会议进展。
他们有更多的个人参与感。
多个故事可以同时编辑。
重新划分优先级变得易如反掌——挪动索引卡就行。
7．故事和任务
故事是可以交付的东西，是产品负责人所关心的；任务是不可交付的东西，产品负责人对它也不关心。
实践TDD（测试驱动开发），几乎每个故事的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”。
避免技术故事。
8．任务板警示标记
这个还是很有必要的，让团队成员对看板越来越深入理解，明白哪里存在问题。
针对团队成员单独的问题，则单独指导改进。
比如站会时“我不知道今天干什么”的成员，让站会继续下去，站会后解决。倘若问题依然存在，就需要衡量一下这个人对于团队的重要性。如果他不是太重要，就试着把他从团队挪走，如果他确实重要，就试着让他跟别人结对，让另一个人充当他的“牧羊人”。
9．让团队坐在一起
互相听到，互相看到，“隔离”。
10．Sprint演示
Sprint都结束于演示。非常认可。
团队的成果得到认可。他们会感觉很好。
其他人可以了解你的团队在做些什么。
演示可以吸引相关干系人的注意，并得到重要反馈。
11．回顾会
潜在主题：“我们怎样才能在下个sprint中做得更好”。
Good
Could have done better
Improvements
圆点投票的民主原则。
每个sprint只关注几个改进就够了。
12．TDD
TDD的确是XP实践中最有价值的投入，它跟结对编程的结合，简直是珠联璧合、天下无双。但TDD比较适合于新系统，而对于遗留系统实施TDD想对要困难很多。同时TDD也催生增量设计，避免了前期的过度设计，好的想法会在TDD的过程中自己冒出来。
13．Sprint之间的休整时刻
“实验日”——分享日。关心员工成长进步。
14．最佳团队规模
更多开发者=更多复杂情况。
7+/-2效应。
“因为Scrum必须针对每一种不同的环境来进行具体实施，所以很难站在通用的角度上讨论何谓最佳实践。”作者放在结尾的一这段话相当的靠谱和诚恳。没错，scrum没有所谓的放之四海而皆准的最佳实践，只有在指导思想框架下的适合本团队的相对的最佳实践。这才是追求真理之路上应该持有的态度。
