00.计划的作用是告诉他人和自己”你现在何处“以及”要往哪里“。你不仅要关注自己的看板墙，还要考虑到团队所处的上下文。有时你需要让上下游的团队和人们了解你的进度状态。
01.估算事实上是深入到工作当中揭示其中的不确定性。因此，估算也可以被看作是风险管理。你想尽早了解那些有风险的以及可能在将来导致问题的未知的事情。
02.计划活动产出了待完成的工作项库存。
03.为了在维持小批量的工作缓冲的同时，综合考虑计划的成本，一个可行的方案是事件驱动的计划方式——在流程中通过特定事件告诉你有能力进行更多工作了。事件驱动的计划可以通过建立简单的信号系统通知你要计划更多条目了，这样的信号系统可以比较容易地工作流中实现并可视化看板墙。
04.即时计划
*即时=恰好需要的时刻
*计划过多的工作带来库存，导致更加不敏捷
*更经常的计划，也意味着更经常的会议
*在流程中创建信号来通知你需要更多的工作了。
*流程中的事件可以驱动它的发生。
05.订货点：当剩下的条目数小于某个值时，就从利益相关人拉入更多的工作。
06.优先级过滤器
*可视化你的优先级设定
*优先级1 = 你需要立即开始的工作
*按产能限制条目，以保证各个工作项的前置时间
*什么是现在我们需要做的最重要的事？
*当有控件容纳更多的优先级1的条目时问的问题
07.迪士尼乐园等待时间
*显示工作的预期等待时间
*计算工作的前置时间
*可以按工作量的大小分别计算（如大、中或小）
*建立与利益相关人的互信
08.估算棘手的地方在于，你要预测未来并确信它会按预期的方式发生，而未来本身就是未知的。为了得到精确的估计，你需要相当了解待估算工作的细节，而且这一切发生在项目的起始——这恰恰是你对於工作了解最少的时刻。
09.应该在估算中避免使用”天数“或”小时数“，因为它可能让你和他人误以为它是真正的天数。例如有些团队使用”相对天数“，者也是为了传达那不是真实的天数。
10.团队经理会觉得一个月完成了34个故事点，因此一个故事点大约可以换算成一天。但这是错误的，它只是此刻你给出的用户故事之间的相对估算。
11.估算还可能受团队动态的影响，如谁在讨论中更强势，或者不同团队的强项、弱项以及经验。对一个团队很难的事情，对另一个团队或许非常简单。
12.故事点：
*相对估算，用以比较工作项的大小，而不是每个工作项的绝对规模
*不能用于团队之间的比较
*常见的序列是斐波那契数列
*选择适合你的数字序列
13.T-shirt尺码背后的思想是给出工作的相对大小，而不是高精度的估计。
14.拆分被估算为XL的条目，直到变成L或更小。这也是管理不确定性和风险的好方法，并有助于限制在制品。
15.T-shirt尺寸估算法
*按大小将工作分组，就像T-shirt的大小一样
*SML最常用
*必要时可以使用XS和XL
*相对估算
*跟踪项目中的真实数据
16.卡片队列
*用以快速估算大量工作项的方法
*任意选择一个工作项，和已排列好的工作项比较：更大还是更小呢？
*当所有的工作项都排列好之后，为他们指定数值：如故事点或T-shirt尺码
17.计划扑克
计划扑克是小组估算的另一个方法。大致过程：
a.把扑克卡片（稍后说明）发给每个参与者。
b.选择一个带估算的工作项，兵想团队简要解释
c.讨论这个工作项，并回答相关问题
d.每个人都觉得足够清楚后，开始进入估算环节
e.每个人选择一张带有对应点数的扑克卡片，但不要让其他人看到
f.数1,2,3同时向其他人展示自己的扑克卡片
g.这一步是最有意思的，如果大家的意见一致，你们就达成了估算，可以开始下一个了。
h.一直重复，知道你们就估算大小达成一致。小的不一致是可以被接受的，但应该是比较接近的值。
18.目的在于讨论，而不是估算，这一点在怎么强调也不过。要鼓励提问和讨论：它让学习的得以发生，新想法被发现，既定有事实被挑战甚至放弃。有时，我们无法得到答案，因为太多的未知，这本身也是一个有用的结论。利益相关人也不愿意在这种情况下开始项目。为了保障估算过程的效率和效果，你要确保能够回答问题的人在场。
19.计划扑克：
*是一个消除误解，激发讨论和发现需求真是含义的好工具
*讨论：选择一个数字，展示给团队，如果不能达成一致->继续讨论->达成一致->进入下一个估算
*讨论比估算重要
20.金发女孩
*不要估算，而是把工作项分割成合适的大小（组合较小的工作项、拆分较大的工作项）
*让待办事项里的条目变得大小均匀
21.精益的实践者所说的节律是指工作的节拍或旋律，它是流程的心跳。
22.看板知识三个基本的原则（让工作可视化、限制在制品、帮助工作流动）
23.为什么需要计划，有没有替代方案？除了理论和理性让我们尝试做更小的计划和估算工作外，很多看板团队在更多使用看板实践和原则后发现，计划和估算的需求逐渐变小了。
24.不要知识因为看板没有要求做计划而停止计划（以及其他帮助你做好工作的方法）。太多的团队以“看板中没有计划”为由而停止做计划。不要这样！你可以做的更好。做一个类比，看板也没有说过任何关于代码质量的问题，甚至也没有说编码或者测试，难道你就能直接部署代码吗？
25.IT部门或项目的目的是为了让业务运行得更只会、更方便、更好。
26.软件本身不是重点，在软件的背后是有人想要工作得更好、更顺利和更有意思，否则软件就没有存在的理由了。让我们称这个人为客户。
27.如果你不知道客户是谁，就从钱开始，想想谁买单？预算从哪里来？他们的钱优势从哪里来的？这就是你的客户——你应该关心他们。
28.当更多的估算并不能帮助你发现更多的知识，这时化更长时间来估算就没有意义了。
29.计划本身毫无价值，但计划的过程是一切。
30.通过不断向前看以及自我挑战，来尝试新的、更好的方法，不断地学习。
31.小结：
*我们先讨论了在什么时间计划，以及发现计划时机的不同方法；不要太早也不要太迟——在需要时计划
*计划和估算经常是应团队周边的人要求去做的，为此我们也简要讨论了如何把工作刘翔上游和下游扩展
*绝对估算比相对估算要困难得多，所以我们倾向于使用相对估算。(故事点和T-shirt尺码)
*估算技术（卡片队列、计划扑克、金发女孩）
*节拍是所处流程的自然节律。在基于迭代的流程中，迭代的开始和结束就是自然的节拍
*应用看板方法，可以设置适合评审、计划、延时和回顾等各个活动的节拍。不需要把他们和工作流绑定在一起
*最后，我们回退一步，思考了计划和估算的必要性
a.使用看板的团队发现了更紧密的反馈循环，计划的必要性降低了
b.客户要的是业务能力提升，而不是计划和估算
c.如果你在发现新的信息，那么计划和估算就是有用的
d.“#不做估算”运动谈到了放弃估算，发现不依赖估算而高效工作的方法。