Planning Poker with multi-functional teams
Hi everyone,
What's your experience with planning poker in a new multi-functional team working on a new product?
For example, say the team consists of back end specialists (e.g Python), front end specialists (e.g. iOS) and QA testers. Each of them know a little about how each other work, but not enough to accurately estimate each others work yet (as they are a new team).
Now say for example you are estimating a particularly heavy back end ticket, the iOS developers have no idea how to estimate that yet; the backend developers obviously do. Do the iOS developers usually abstain from voting in your experience?
Now say you have a particularly complicated piece of work, but the complexity is all round; both front end and back end heavy. Neither of the specialists no how to estimate each others work, so how would you expect the team to compare this to the previous ticket (where half of the developers had no idea)?
My gut instinct tells me to keep asking everyone to compare against previous tickets and to re-estimate items at the top of the backlog as the more the team becomes familiar with each other. But that doesn't make it any less tough to being with though!
Any tips?
Cheers,
Steve
Play the cards, discuss, explain, play again, and reach a consensus. The value of planning poker lies more in developing a team understanding than in the numbers arrived at.
Play the cards, discuss, explain, play again, and reach a consensus. The value of planning poker lies more in developing a team understanding than in the numbers arrived at.
I think it is generally helpful for all team members to make an initial estimate, because it highlights where there isn't a shared understanding.
In my opinion*, it would be fine for the less-certain team members to re-estimate, or to abstain, on the 2nd vote, as long as the whole Development Team can stand behind the resulting estimate.
It might be useful, once this particular item is done, for the Development Team to discuss whether they thought the estimate was good, and what (if anything) should be done differently in the future.
----
* A lot of people have opinions on story points. Whether and how the Development Team use them should be something the team discuss.
Thanks for your help. What I'm going to do is, is run through each of the completed items in the sprint retrospective and see whether the teams thought the estimates were good.
Cheers,
Steve
Hi there, I face a similar issue. Back end and front end estimate in completely different ways, meaning that this is difficult to have common tickets between the 2 (common projects, bugs, or hiring tasks). It also makes it difficult to make sure we have the right amount of work between FE & BE. Should I try to find a common baseline, or should I just keep looking at FE & BE separately?
If your Development Team is made up of front-end and back-end developers, then the Development Team should be estimating as one. But if you are creating stories that are focused on the separate ends, I recommend you start learning and coaching on doing vertical slices rather than horizontal.
In my opinion your entire problem is because the Development Team sees themselves as separated front-end and back-end developers. They need to see themselves as full-stack. True, they may have different strengths and it is possible that a front-end and a back-end developer need to work together to deliver an increment of value but they should work as a team rather than as 2 separate teams.
It also makes it difficult to make sure we have the right amount of work between FE & BE.
How about focusing on the value you are delivering instead of having 40 hours/week of work for eveyone? And where is it written that a front-end developer can not do work on a back-end? Having the two disciplines pair together can often prevent problems because the design will evolve naturally as the two communicate. They can test the work they are doing as they build as a way of validating their decisions.
Should I try to find a common baseline, or should I just keep looking at FE & BE separately?
You should not do any of this. But you should be helping the Development Team to understand how this practice could be adverse to the results that they are striving to achieve.
Now that I have said all of that, I am going to ask a question that could invalidate all that I wrote. Does the Development Team see this as a problem? Are they consistently delivering increments of potentially releasable value in each Sprint? It could be that you are trying to see a problem that isn't there.