We have a project manager that is adamant about planning poker. I have found that this adds stress to everyone on the team, and the times are always wrong. We have different skill levels on the team and expected to complete a task within the given time period. We estimate as a team and then take the average. I find that this adds stress to the team, and decreases motivation/morale.
How can we address this situation?
Is Planning Poker Bad for Software Development Teams?
This is the wrong question to ask. Planning poker is a tool. Asking if planning poker is bad for software development teams is like asking if a screwdriver is bad for plumbers. If the tool fits the job then it's a good tool, if not, then it's not.
The real question you should be asking yourself is:
Why is my project manager so adamant about planning poker?
You don't add any extra context to be able to answer this but I'm thinking at two immediate reasons:
An estimate is an approximation. The fact that you provide estimates as 3.75 hours (as you mention in your comment) means that you are ignoring this fact, you or maybe your project manager.
I suggest you read the following posts for hours vs story point estimation and why planning poker is a good tool for many teams:
Another thing to add is that planning poker is a consensus-based estimation techniques. That means that when you get vastly different estimates, the team members discuss it until they reach a number that they all agree with. They don't just estimate as a team and then take the average. An average completely destroys the discussion that needs to take place in order to reach consensus and also destroys the spread of the different estimations people provided. If a senior says 1 day, and a junior says 5 days, getting back (5 + 1) /2 = 3 days is not a good estimate because the senior will finish early while the junior will probably be late. Then what happens if the junior works on the task? The project manager will pressure them to finish the work in 3 days even though they thought it will take 5 (and that was probably wrong too and most likely they will finish in 7 days).
Planning poker is a tool. Story points are tools. Your project manager should probably learn what these tools are all about before insisting on estimating in hours and keeping people accountable for estimates that look forced from what you are describing.
Planning Poker isn't the only way to estimate and lots of teams get on well with other methods. More experienced teams may find they can reach a consensus estimate via a quick conversation instead.
The idea of poker is that it encourages the whole team to contribute an estimate and that everyone's opinion is important. Averaging is reasonable if the deviation in estimates is small. If there is a large spread of estimates then averaging is just a way of ignoring a confusion rather than clearing it up. Whatever method you use, the priority is to ensure the team feel that they own the estimates and that they have confidence in the numbers agreed.
Trying to do absolute estimates with 15 minutes precision(!) is surely a huge part of your problem. Of course that puts unreasonable pressure on the team, it encourages them to "game" the estimates and is not transparent ("ideal hours" are not really hours so why pretend they are?). On the evidence you say that method is failing, so fix it. If poker is unpopular then maybe don't use it straight away but you can still do relative estimation with story points instead of hours, use modified Fibonacci numbers, encourage discussion, look for consensus and avoid averaging.
We estimate as a team and then take the average
Good grief, don't take the average! That's not how planning poker is played.
Here's how I teach my teams:
Junior devs may feel uncomfortable when they are first asked to participate, and may need some coaching and encouragement that it is okay their estimates are different, and that it is helpful if they ask what might seem to them like "dumb questions", because their question will prompt an explanation that might bring up something that no one else had been thinking about when they made their estimates. When played this way, there is less pressure on junior devs because if they "get it wrong", that will be clarified during the discussion and this is an opportunity for them to learn by doing.
I don't feel strongly about whether to play in story points or in ideal days, but I do feel strongly that a Fibonacci deck should be used. Not only because the increasing bin sizes reflect how uncertainty grows as a function of size; but also because it's a lot easier to choose between 5 and 8, say, than between 5 and 6. The bigger gaps make the choices starker and therefore easier.*
*At least, it's easier once everyone gets used to the idea that it's not "accurate". It's not supposed to be accurate; it's an estimate. When you are estimating how much money you'll spend at the grocery store, you don't use accurate prices, "bread costs 2.23 and kleenex costs 3.86 and a candy bar costs 1.25". You say "ok, bread is about 2, kleenex about 4, candy bar about a buck, I want 2 candy bars so that's about 8, better bring $10 to be sure."
I introduced planning poker to my teams in order to help them be more comfortable with estimation, and learn from each other how to do it well. But honestly, the benefit in knowledge sharing and scope clarification is so high that at this point I almost consider the estimation to be a secondary goal.
I hope this helps! Good luck, and try to have fun when you play.
It's no bad, and neither is stress, but since you're asking the question, it may be the source of a larger issue.
I've been on teams where I've liked planning poker and teams where I've loathed planning poker, so I would say that generally "it's good", but in the wrong context, "sometimes it's bad".
When I said it may be part of a larger issue, such as misunderstanding the story. If when pointing you get wildly different numbers as you say, you have to make a decision of what to do. Do you:
I'd encourage you to go with the third option. Simply state that the team doesn't have a clear grasp of the story, and you'd like to take some time outside of this meeting (to save everyone's time) to get a better understanding. The next time you play planning poker, that story should be less stressful, but maybe another one comes up where you need to make a decision on what to do.
As was mentioned in another answer, let it be what it is: a tool for not only estimating, but for determining if the team has an understanding of the complexities involved in the story. Further, I'd suggest that when you take time to come up with the complexities of the story, write them in the story; that way the next time you do planning poker you can say "Here's the story, and here are it's complexities, what are your estimates?"
How can we address this situation?
This depends on whether your project manager is willing to adjust his approach to planning poker or not. But she needs to understand that her approach is not just creating stress, but also includes bad math and is a bad tool to make predictions. Here is the approach I would suggest to her:
At the end of the current sprint, count all the tasks that were completed (according to whatever you define as 'completed') and add up the hours you have assigned to these tasks. Take this number and use it as a prediction of how much "hours" your team can realistically get done next sprint. Now is a good moment to accept that "hours" is not really hours and you rename "hours" to "points". Next thing you do is that you treat points as a prediction for the aggregated team performance over the next sprint, but don't use it as a hard deadline for task.
Let's say you completed 66 hours worth of tasks. That means that your team can do 66 points of tasks per sprint. Next sprint you will add tasks to the backlog until you reach 66 points and you have a realistic prediction of how much the team can achieve in that time. This should work for your product manager, because now she can more realistically predict how much of the workload will be done. You can even estimate stories for months ahead and get an idea of what will be done by the end of the quarter etc. (with some caveats of course).
Moving away from estimating hours, which can be wildly different depending on the individual, will also make sure that the estimates are aligning better. Developer who are usually lower in their estimates should calibrate to higher estimates and developers who are usually higher should calibrate down, points are just becoming an abstract unit of work: A junior might estimate a story as 5, if it takes him three days, while a senior sees the 5 as something that can be done in half a day.
If your product manager does not agree to changing her approach I would try to get together as a team and fix it unilaterally: Agree that to make estimates that everyone can follow, everyone cannot estimate how much time they would need themselves to finish the task, but how much time the team member with the least experience on that task would need. This way every team member can stay within the given estimates, as it is easier to work slower than full capacity than to go faster.
Either way, you should reach a situation in which everyone roughly comes to the same estimates.
As @NKCampbell points out in a comment, normally a planning poker deck doesn't include a 4. This is not a bug but a feature (no pun intended): the idea is that as complexity increases, the associated effort increases exponentially rather than linearly.
Also, in my experience, the numbers are typically treated as story points or some other abstract unit of work (as pointed out by @Helena). Agile practitioners (coaches) in my experience usually recommend this (and strongly recommend against doing estimates in hours) -- precisely because "8 hours" is usually interpreted as "one calendar day", and very few people are actually productive for 8 hours per workday.
And the idea is to measure how many story points the team can get done in a sprint; that's your "velocity". Measuring at the team (rather than individual) level tends to eliminate the discrepancies due to difference in experience and/or skill.
I'd also note that most agile practitioners I know consider it an important rule of thumb to not adjust an estimate down: if a more senior person says 3 and a more junior person says 5, the team should go with 5 (because the junior person might end up working that particular task). This may be a sgnificant factor in why your estimates are off.
So I am/ we are sorry to be the bearers of bad news, but it sounds like your manager is doing it wrong. That said, they may be reacting to pressure from their superiors.
How to approach your manager would probably be better asked on The Workplace. But for what it's worth, my advice would be:
Arm yourself with as much knowledge as possible. Read Kent Beck, Martin Fowler, Bob Martin, Mike Cohn et al. Encourage people on the team to do likewise -- maybe several of you can each read a book or a few articles and report to the others on what they learned.
Come up with one or two specific recommendations based on agile best practices. For example, trying out story points instead of hours-based estimates.
Approach your manager, as non-confrontationally as possible. For example, say that you don't feel your team is getting the most bang out of agile; you think the team could be more productive and morale would be improved if <<insert your recommendation here>>. Point to your research and show that your recommendation reflects best practices.
I would emphasize that you're making these suggestions because you want the team to succeed, but also because you want your manager to succeed. If you haven't already, you might ask about their goals and how you can help them achieve those, etc., etc., etc.
Planning poker is a simple tool for estimating, and it works well enough:
It also helps building trust and and respect for other team members.
