How to use Planning Poker Card for Cross - Functional team?
Hello everyone,
My team has been using the Scrum framework for more than a year, and we have found that since using it, we have overcome all the complex tasks quite smoothly. But in the process, we also encountered a lot of difficulties. The current difficulty we are facing is estimating Story Points using Planning Poker Cards.
The problem we have is that, in the cross-functional team including: Dev, Art, Game Design, Tester, Marketing … And when choosing the point for the Story, we have difficulty that the Devs only have enough expertise to estimate points for Dev, similarly for other positions. We have tried to let everyone estimate together, but it is not effective, and the answer we usually get is: I cannot estimate for other positions. So, we came up with an idea, which is:
Let the Dev position estimate their points, similarly for other positions. Then we will add them all up to get the final point. For example:
Dev estimates for Story A is 5 points.
Art: 3 points
Tester: 5 points.
then the point for that Story will be: 5 + 3 + 5 = 13 points.
Can you tell me if this is correct? If not, is there any way to solve it?
Would you say that the Developers have a shared sense of joint accountability and commitment? It sounds as though they view each other as holding different "positions". How effectively do they collaborate when actually doing the work, considering the difficulties that are exposed when trying to estimate it?
There is no "right way" to estimate. After all, an estimate is a just a guess made at a point in time based upon the information available at that instance. Everyone estimates differently. In fact, each of the Developers have their own "method" of arriving at their individual estimate so even when 4 Developers rate something a 5, it may not be the same.
The idea of using Story Points is to come up with an estimate that is relative to other work that has been done. It uses a modified Fibonacci sequence because as the numbers increase, so do the margins between them. This helps teams get past the issue of how much bigger is a 6 from a 5. The margins increase as the complexity and unknowns increase.
If your team has been working together for more than a year, then there should be some history that they can use to learn. The ones that write code can learn about the marketing side by asking questions, looking at the relationship of the code they wrote to the complexity of the marketing activities, etc, etc. It isn't expected that everyone on the team will know how to do all of the work, but it is expected that everyone on the team is capable of understanding all of the work. To me, this sounds like a situation where people don't want to take the time to understand anything that others are doing, unless the others are doing the same type of activity as themselves.
Consider a soccer team. There are specialized positions on the team. Each position has some specific purpose for being on the field. But if you ask anyone on the team what the other players are doing, they will be able to explain. And in many cases, they could help anyone on the field. That is a cross functional team of individuals all working on a common goal. Software/Game development should not be any different.
Thanks Daniel and Ian
I have a clear understanding of the issues within my team now.
