I always stress story sizing over estimating. If you can minimize the variation in size between stories, then estimates become much less interesting. That is, estimation activities lose their value when the difference in size between any two stories is small, which helps fast teams recoup the cost of estimation and put it toward something productive (like building product).
With that in mind, I would suggest proactively pruning the backlog and splitting five point stories into smaller ones (still thin vertical slices) whenever possible. Until your team is experienced, I'd suggest you continue to have estimation parties, but prompt a default estimate of 1 point to each card, with a quick consensus check or discussion as to why any justify a bump to a 2 or 3. For anything that's clearly bigger than a 3, I'd suggest challenging that one of two problems is present: the baseline value of "1" is too small or the story should be split (either made more specific or tracked as an epic).
As the team establishes a decent velocity, the activity can hopefully shift its mindset from estimation to mere story vetting. That is, the question during planning of "how big is this story?" becomes "is this story abnormal?" The latter question takes significantly less time to answer.
Most Agile methodologies suggest that you should estimate in points. However, there are many successful teams out there - including several advanced and highly productive Kanban teams - who estimate in hours. Points come with their own games, perverse incentives and problems. YMMV. Anyway...
I've heard figures of 25% more dev-hours for a pair completing a task. So, the task would be finished in 62.5% of the time, using two developers instead of one. However, the quality of and knowledge-sharing often increases too. Since bugs = rework and rework takes longer than doing it the right way the first time, pair-programming usually pays for itself. This differs for different tasks and levels of skill, eg: simple bug fixes, novice programmers, etc.
In my experience 2/3 of the time is a pretty good ballpark figure. It's longer than 1/2 but less than it would be with just 1 person.
Sallyann Freudenberg is a good name to look up regarding pair programming research. You could also check out the refs on the Wikipedia page: http://en.wikipedia.org/wiki/Pair_programming
Pair estimates how long it is going to take them. Any estimate is based on experience - the longer experience team has with the project, with technology and with working together in pairs the better the estimates will be. Any arbitrary percentages like add 25% for pairs etc. are of any use only at the very beginning - with new project and new team on new technology - where you have nothing else to base estimation on yet. As soon as experience starts building the estimates will improve.
Remember though, that they are just this - estimates, that is our best guess of the future derived with the help of experience and knowledge from our understanding of the present. It's like weather forecast - the more data we have, the more experience forecasters have the better it is, but it is just a prediction, not reality.
Which is why points are so great, because they help you estimate one parameter you can - how "big" the tasks at hand are.
1) A simple, concrete way to think about estimating units is the number of check-ins it would take to complete the story.
If you're doing TDD, continuous integration and refactoring you'll be working in small, chunks of work, keeping the build green and checking in regularly so under those conditions single check-ins can be a meaningful unit of estimation.
2) Alternatively, think about blocks of uninterrupted pairing time in a day e.g. after stand-up to coffee break, after coffee break to lunch, after lunch to mid-afternoon break, mid-afternoon to going home time - say 4 periods a day.... so say 4 units is a single day. That gives you a bound on what you could expect to do in an interation...
Personally I go for the number of check-ins, because I can sketch out roughly the tasks involved and get an idea of check-in numbers.
The great thing about number of check-ins is that it doesn't matter if you're pairing or not - you're just tracking what you can get done.
发布评论
评论（5）
你用点来估计。一对可达到的点数称为速度。检查这个：http://en.wikipedia.org/Planning_poker
You estimate using points. The number of points achievable by a pair is called velocity. Check this: http://en.wikipedia.org/Planning_poker
我总是强调故事规模而不是估计。如果您可以最大限度地减少故事之间的大小差异，那么估计就会变得不那么有趣。也就是说，当任何两个故事之间的大小差异很小时，估算活动就会失去价值，这有助于快速团队收回估算成本并将其用于富有成效的事情（例如构建产品）。
考虑到这一点，我建议尽可能主动修剪积压的工作，并将五个点的故事分成更小的故事（仍然是薄的垂直切片）。在您的团队经验丰富之前，我建议您继续进行估算，但提示每张卡的默认估算为 1 分，并快速达成共识检查或讨论为什么有理由将其提高到 2 或 3 分。任何明显大于 3 的东西，我建议挑战是否存在两个问题之一：“1”的基线值太小，或者应该拆分故事（要么变得更具体，要么作为史诗进行跟踪）。
随着团队建立了良好的速度，该活动有望将其思维方式从估计转变为单纯的故事审查。也就是策划时的问题“这个故事有多大？”变成“这个故事异常吗？”回答后一个问题所需的时间要少得多。
I always stress story sizing over estimating. If you can minimize the variation in size between stories, then estimates become much less interesting. That is, estimation activities lose their value when the difference in size between any two stories is small, which helps fast teams recoup the cost of estimation and put it toward something productive (like building product).
With that in mind, I would suggest proactively pruning the backlog and splitting five point stories into smaller ones (still thin vertical slices) whenever possible. Until your team is experienced, I'd suggest you continue to have estimation parties, but prompt a default estimate of 1 point to each card, with a quick consensus check or discussion as to why any justify a bump to a 2 or 3. For anything that's clearly bigger than a 3, I'd suggest challenging that one of two problems is present: the baseline value of "1" is too small or the story should be split (either made more specific or tracked as an epic).
As the team establishes a decent velocity, the activity can hopefully shift its mindset from estimation to mere story vetting. That is, the question during planning of "how big is this story?" becomes "is this story abnormal?" The latter question takes significantly less time to answer.
大多数敏捷方法建议您应该以点为单位进行估计。然而，有许多成功的团队 - 包括几个先进且高效的看板团队 - 以小时为单位进行估算。积分伴随着自己的游戏、不正当的激励和问题。 YMMV。不管怎样...
我听说一对人完成一项任务的开发时间可以增加 25%。因此，使用两名开发人员而不是一名开发人员，该任务的完成率为 62.5%。然而，知识共享的质量和知识共享往往也会提高。由于错误 = 返工，而返工比第一次以正确的方式进行返工需要更长的时间，因此结对编程通常会收回成本。对于不同的任务和技能水平，这会有所不同，例如：简单的错误修复、新手程序员等。
根据我的经验，2/3 的时间是一个相当不错的数字。它比 1/2 长，但比只有 1 人时要短。
Sallyann Freudenberg 是一个关于结对编程研究的好名字。您还可以查看维基百科页面上的参考文献：
http://en.wikipedia.org/wiki/Pair_programming
该数字主要由Alistair Cockburn 和 Laurie Williams 报告中的数据：http://collaboration。 csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
Most Agile methodologies suggest that you should estimate in points. However, there are many successful teams out there - including several advanced and highly productive Kanban teams - who estimate in hours. Points come with their own games, perverse incentives and problems. YMMV. Anyway...
I've heard figures of 25% more dev-hours for a pair completing a task. So, the task would be finished in 62.5% of the time, using two developers instead of one. However, the quality of and knowledge-sharing often increases too. Since bugs = rework and rework takes longer than doing it the right way the first time, pair-programming usually pays for itself. This differs for different tasks and levels of skill, eg: simple bug fixes, novice programmers, etc.
In my experience 2/3 of the time is a pretty good ballpark figure. It's longer than 1/2 but less than it would be with just 1 person.
Sallyann Freudenberg is a good name to look up regarding pair programming research. You could also check out the refs on the Wikipedia page:
http://en.wikipedia.org/wiki/Pair_programming
The figure is mostly borne out by the data in this report by Alistair Cockburn and Laurie Williams: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
两人估计需要多长时间。任何估算都是基于经验——团队在项目、技术和结对合作方面的经验越长，估算就会越好。任何任意的百分比，比如成对添加 25% 等，都只在一开始才有用——新项目和新团队采用新技术——此时你还没有其他可以作为估计基础的数据。一旦经验开始积累，估计就会改善。
但请记住，它们只是 - 估计，这是我们在经验和知识的帮助下得出的对未来的最佳猜测。这就像天气预报一样，我们拥有的数据越多，预报员的经验越多，效果就越好，但这只是预测，而不是现实。
这就是为什么分数如此重要，因为它们可以帮助你估计一个参数——手头的任务有多大。
Pair estimates how long it is going to take them. Any estimate is based on experience - the longer experience team has with the project, with technology and with working together in pairs the better the estimates will be. Any arbitrary percentages like add 25% for pairs etc. are of any use only at the very beginning - with new project and new team on new technology - where you have nothing else to base estimation on yet. As soon as experience starts building the estimates will improve.
Remember though, that they are just this - estimates, that is our best guess of the future derived with the help of experience and knowledge from our understanding of the present. It's like weather forecast - the more data we have, the more experience forecasters have the better it is, but it is just a prediction, not reality.
Which is why points are so great, because they help you estimate one parameter you can - how "big" the tasks at hand are.
1) 考虑估计单位的一种简单、具体的方法是完成故事所需的签到次数。
如果您正在进行 TDD、持续集成和重构，您将从事小块的工作，保持构建绿色并定期检查，因此在这些条件下，单次检查可能是一个有意义的估计单位。
2) 或者，考虑一天中不间断的配对时间，例如起床后到咖啡休息时间、咖啡休息后到午餐时间、午餐后到下午休息时间、下午到回家时间——比如一天 4 个小时....所以说4个单位是一天。这给了你在交互中期望做的事情的界限……
就我个人而言，我喜欢签到的数量，因为我可以粗略地勾勒出所涉及的任务并了解签到的数量。
签到次数的好处在于，您是否配对并不重要 - 您只需跟踪自己可以完成的工作。
1) A simple, concrete way to think about estimating units is the number of check-ins it would take to complete the story.
If you're doing TDD, continuous integration and refactoring you'll be working in small, chunks of work, keeping the build green and checking in regularly so under those conditions single check-ins can be a meaningful unit of estimation.
2) Alternatively, think about blocks of uninterrupted pairing time in a day e.g. after stand-up to coffee break, after coffee break to lunch, after lunch to mid-afternoon break, mid-afternoon to going home time - say 4 periods a day.... so say 4 units is a single day. That gives you a bound on what you could expect to do in an interation...
Personally I go for the number of check-ins, because I can sketch out roughly the tasks involved and get an idea of check-in numbers.
The great thing about number of check-ins is that it doesn't matter if you're pairing or not - you're just tracking what you can get done.