There are a number of reasons that Planning Poker might not function well for this scenario. Among them:
- The feature being estimated doesn’t have much uncertainty. If we are in content production, there is more of a flow of hand-offs from one discipline to another and we should probably focus on the flow rather than a single size estimate. When this is the case, both the programmer and the artist are correct for their parts.
- The work being estimated has been dis-aggregated to the point (discipline-centric) where planning poker doesn’t make sense. If you've broken down backlog items to the task level, just estimate how you would normally do it in sprint planning. If you have backlog items such as "implement this function" or "add this model", you've probably broken down your backlog too far.
- The implementation has already been decided (too early perhaps?) so that the planning poker discussion is less meaningful. I find planning poker leads to great design and goal discussions between disciplines. If the decision of "how" a feature is going to be implemented has already been made, then planning poker falls into the trap of #2.
The challenging part of agile is the “people over process” value. Finding what makes sense for a team on their agile journey is key. When I coach a team, I sit with them and we come to an agreement about what the ideal level of planning might look like. We want to be able to respond to change, to have a plan that is not so detailed that it’s obsolete the week after we create it and not so burdensome that we ignore its maintenance. Most game developers know that detailed plans are never accurate and are usually so optimistic that they result in a death march to hit a schedule. We come to an agreement that we want to avoid a death march and we want to make a better game.
When we have this shared agreement, they become partners in exploring planning practices and eventually innovate what works best for them.