FAIL #2: You Don’t Discuss High and Low Votes This lets the group settle on more natural high and low estimate values thus increasing the accuracy of the overall numbers. To get around this problem, try to keep everyone from indicating how they intend to vote. This is a great way to decrease the effectiveness of the Wisdom of Crowds. Anchoring happens when someone or something provides a subtle or not-so-subtle context for the estimation that causes everyone to shift their guesses. It’s pretty likely that this didn’t just happen to you either – at least a couple of other people on your team had that same reaction and voted lower than they initially would have guessed. The architect thinks it’s tiny and you have 1) zero desire to contradict him and 2) zero desire to look like an idiot in front of your team – so you decide to play it safe and vote a 5.īy voting ‘5’ (instead of ’21’), your personal vote just got skewed. Let’s vote.” So, initially, you were thinking ‘21’ but now you’re not so sure. Now just before the Scrum Master says “ok…let’s vote”, your lead architect says “oh come on! I can’t believe we are even bothering with this! It’s a miniscule, tiny, two-second fix! Ok. The Scrum Master reads off the PBI description and you’re thinking that it sounds like a big job and you intend to vote ’21’. Let’s say your team is getting ready to do the first round of voting. In order for the Wisdom of Crowds to work, everyone needs to vote independently without undue influence. Put another way, any individual’s estimate is probably pretty terrible but the combination of all these individual estimates is much more accurate. What works well about this is that they’re using a phenomenon called ‘The Wisdom of Crowds.’ The Wisdom of Crowds states that when a group of people work independently to vote on an estimate of something, the average of all the estimates will be remarkably close to the actual value. Initially, there probably won’t be a clear group consensus on the size/effort of the PBI so the team will likely go through several cycles of discussion and voting before they reach a consensus. 1.2.3.vote” and everyone displays a card with their personal estimate of the size/effort of the PBI. Then the facilitator says “everyone vote on the count of 3. Someone reads the text of a PBI out loud followed by a brief discussion of the meaning of that PBI. These numbers are the numbers you’ll assign to a PBI for its Story Point effort value. When you play Planning Poker, your team comes together and each person brings a deck cards with values based on the Fibonacci Sequence – 1, 2, 3, 5, 8, 13, 21, 40, & infinity. One of the most common ways to estimate is using Planning Poker. If you want to do Scrum well, you need to estimate your Product Backlog Items (PBIs). A Brief Introduction to Scrum Planning Poker This article will give you 5 time-tested ways to fail at Planning Poker – and how to avoid them. And if you’re bad at Planning Poker, you’re probably just as bad at estimation, too…and that’s something you’ll definitely want to get better at. Frankly, lots of teams just plain stink at Planning Poker. (By my estimates, I’d say that somewhere between 0 and 100% of teams use it.) It’s a simple and effective way to do software estimation that’s easy to understand and implement.Ĭonsidering how simple it is, you’d think that all teams would do it well – but it’s amazing how often teams are bad at it. If you’re doing Scrum, chances are high that you use or at least have heard of Planning Poker.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |