敏捷扑克是什么？
其实应该叫“估算扑克”更准确一些，本质上是扑克牌，基于Delphi估算原理，可以快速估算出需要的数字。
关于扑克牌上的数字
估算扑克牌上的数字，有的牌是自然数排列，有些是斐波纳契数，有些则是不连续自然数。具体选用哪种扑克，要根据被估算的内容的跨度大小而定，如果估算值跨度在10倍以内，那么采用顺序自然数比较好，如果数值跨度较大，达到10倍以上，那么采用斐波纳契数比较好。一般而言，估算软件开发工时的话，自然数可能更好一些，毕竟数值都不大，跨度也不会很夸张。
扑克估算的意义与价值
第一点，自然是要获得一个相对较为准确的数字。
和其他估算方法比，使用扑克牌的方法，能够带来一个额外的好处：促进团队成员间的交流，让大家共享、了解更多的信息。扑克牌估算中，有一条规则是：当估算值差距大于可接受范围内的时候，估算数值大的人和估算数值小的人，要各自陈述自己的意见，陈明是什么原因/根据促使自己做了相应的估算。通过这种方法，可以让所有人都有机会发言，分享自己所了解到的知识，而其他人则在这个过程中了解到了很多其他人的知识，这些知识在接下来的开发工作中，都是很有用的。
会不会有人从来不发言呢？
答案是，不会的，不可能有人每次都能够估算出平均值，因此而避免发言。如果这有这么一个人的话，哈哈，那千万不要放跑这个人，也别打牌了，全由他一个人估算就好了，又快又准，哈哈～～（发白日梦中……）
如何使用敏捷扑克？
项目组成员
Scrum Master：Lily，后排左侧，QA出身，工作细心踏实。
Product Owner：勇哥，后排右侧，资深ITer，做软件无数。
成员共有四名：前排，从左至右：陈师傅，开发组的老大哥；小洁，新人，表现相当出色；阿典，开发组里的帅哥；Pan，真正的高手。
分牌
每名参与估算的成员分得相同花色的一组牌，两张Joker不参与估算
敏捷扑克和普通游戏扑克一样，也有54张牌，也拥有4种花色（每种各13张）和两张Joker。敏捷扑克的每种花色均是一组13张牌组成的估算扑克牌，牌正面上印刷有供估算用的数字与符号，数字分别是1/2，1~10和20，符号为“！”，代表一些未知情况，如无法提供准确估算值等。
一副估算扑克可供四人使用，如果参与估算的人员多于4人，可以使用多副扑克。关于参与估算的人数方面，一般我们推荐4到8人参与估算；人数太少，会使估算结果偏差很大，人数太多，会拉长估算时间，降低估算效率。
讲解Backlog
产品负责人勇哥从Backlog中选择一个条目，为大家详细讲解该条目
团队成员针对该条目进行讨论并提出问题，勇哥逐一解答大家的问题；阿典思路敏捷，总能想到很多大家意想不到的东西来。
这个步骤是团队和产品负责人之间的交互的环节，帮助团队和产品负责人共同加深对条目的理解。同时产品负责人也会根据大家的反馈，及时修改条目，完善条目。
在讲解条目过程中，千万不要制定该条目的负责人或明显的倾向于某些人来做这个条目，这样会大大降低不负责该条目的团队成员的积极性，甚至会扰乱估算的秩序与结果。
估算
当团队成员确认已经对该条目完全了解、无任何重大问题后，大家开始对该条目进行估算，同时选出代表自己估算值的纸牌，但不可立即亮牌。在估算过程中，为避免干扰估算结果，团队成员之间不可以互相商讨；
估算时，我们经常会估算相对值，而不是绝对值，如一个功能的开发难度或者代码规模，估算单位经常使用点，而不是绝对的时间或者数量，这时我们需要选择一个估算的标准。最简单的方法就是我们选择一个规模中等，大家都比较容易理解的条目，将其设定为一个标准值，比如5，然后再将其他条目和他进行比较，得出其他条目的相对点数。每次估算时，最好使用相同的标准条目，这样对于整个项目的统计有很大帮助。使用相对值进行估算，可以有效的监控团队的生产能力。
选择牌时，牌中央的数字和符号代表了你的估算值，受到纸牌数量的限制，牌面数字不可能包含了全部的可能性，遇到特殊的数字时，我们可以采取组合牌的形式，比如您的估算值为3.5，那么我们可以使用一张3，再加上一张1/2来表示3.5。
+ 
=3.5
当所有成员选牌完毕，大家可以同时亮牌
大家估算的结果是：陈师傅，7；小洁，9；阿典和Pan，3。
同时亮牌的好处是，不会有人跟风出牌，每个人的估算都有其独立思考，这也是扑克估算的精华所在。
争议与讨论
对比每张牌估算值之间的大小，若估算值差距明显，代表大家对该条目的价值没有获得共识，团队需要对该条目价值评估结果进行讨论；
VS 
第一轮出牌的结果分别是3，3，7，9；这四个数字差别很大了，两个个偏小，两个偏大，4个数字的平均值是5.5。这时我们需要让估算值是3的阿典说明为什么他认为只有3点，为何会如此简单；之后我们需要选择9的小洁说明为何她认为数值会比较大；选择7的陈师傅最接近平均值，可以选择发言或者不发言均可。
之后大家可以针对每人的发言进行简单的讨论，讨论过程中，随时可以向产品负责人提问，产品负责人需要回答相应的问题，同时向团队成员的估算发出质疑。在讨论过程中，Scrum Master要维护活动秩序，不要让大家讨论跑题了，也不要深入研究代码编写细节，这些是实际开发是再去解决的问题；还有一点很重要，那就是鼓励所有人都发言，千万不要让老手们或强势的人控制了局势。
共识
重复步骤3、4、5，对该条目重新进行估算，直到团队对于该条目的评估数值达成一致。
一般情况下，最多3轮就可以得出一个比较统一的意见。
第二轮，大家出牌的结果是6，7，5，5，虽然有人很不情愿，但是毕竟大家达到了一个不错的共识：估算结果是6~~
如果3轮之后依然没有得到一个统一的意见，比如第四轮出牌结果依然是2，5，5，8；那么Scrum Muster应当立即中断该条目的估算，取平均值或其他大家比较能接受的值作为估算结果。没有任何一种估算是高可靠度的，扑克也不例外，扑克估算的目的就是为了能够在一个尽可能短的时间内，让团队成员更加多的了解需要做的工作，同时顺带得到一个可接受的估算结果。
