How to do Planning poker with the development team which has multi profiles? (such as BE developer, FE developer, tester)

Ok, once again this is my opinion so don't think I am giving the only answer.

In my opinion you have a total misunderstanding of the estimation activity.  I'll quote you and answer after.

I understand that, in the event (such as sprint planning meeting), ...

You have Sprint Planning confused with Refinement.  The purpose of refining the Product Backlog is to help the Development Team fully understand the stories based on the currently known information.  Sprint Planning is for the Development Team to determine what they forecast they can complete in the next Sprint timebox. If you wait until Sprint Planning to fully understand the stories, the Development Team has not had an opportunity to anticipate the work that is coming up.

And then, the team will show their estimation by the cards.

Sure, cards can be used but there is nothing that says it is the only method.  Planning poker (which you refer to) is an eXtreme Programming practice that has been widely adopted but it is not required in Scrum.  If the team feels that they can estimate the work by using colors then that is perfectly acceptable. 

My question is how the QC engineer can determine the estimation (for example for 8 days (unit is the number of days)) include BE works and FE works?

There is nothing in Planning Poker that says a number is defined by days.  In fact that is a myth that often causes failures (again my opinion).  The estimate is supposed to be a relative measure against other work represented in the Product Backlog. This is how disparate development roles can come to agreement.  During the discussions of the stories, each person should be able to determine how easy/difficult other's work is.  It also helps to have rounded individuals in the team so that no one is a total silo of knowledge.  If the team chooses to organize where work is siloed, there is nothing wrong with that.  But those individuals should help others understand how they do their work and how to understand the efforts associated to that work. As the team estimates and do not agree, everyone should discuss the highest and lowest estimate starting with the person that provided that estimate.  Have them explain how they arrived at the estimate.  As that discussion occurs, people should start to better understand the entire body of work.  Over time, people will start to come together on their estimates.

Do not expect it to happen quickly.  It takes time for some teams to start getting good at this.  It helps to revisit some of the estimates that were made vs the actual work effort during a Retrospective.  But DO NOT RE-ESTIMATE at that time.  There is no benefit from it. Just use the past to learn more for the future. 

I suggest that you take time to read the Scrum Guide carefully.  Pay close attention to anything that speaks to estimation and refinement.  Those are the parts that you need to understand.  Notice that no where is there a method described on how to do it. There is only mention that the Product Backlog should be relatively estimated.

Hope this helps and I really look forward to hearing other's opinions. 

However, there are multiple professionals in the development team such as BE engineer, FE engineer, QC engineer. It can be that the QC engineer doesn't know how the BE engineer does the work and how long. So, My question is how the QC engineer can determine the estimation (for example for 8 days (unit is the number of days)) include BE works and FE works?

Team members will bring different understandings and experiences, not just in refinement but throughout the Sprint. If people cannot collaborate when estimating, there is little chance of them doing so once the work is underway. So, how do you think teamwork ought to be demonstrated? What kind of behaviors should be in evidence?

Hello @Dainel

You have Sprint Planning confused with Refinement.

I have read again the Scrum guide. I misunderstood about the Sprint Planning and Refinement. Thank you very much.

There is nothing in Planning Poker that says a number is defined by days

Yes, agree with you. There is nothing requires the number is days. This is just my example. I have researched more on the internet about story point after I had read your comment. The story point is a better suggestion for The Backlog refinement. 

I misunderstood about the estimation by using story point (to compare the relative size of each product backlog item) in the Backlog refinement with the decomposition and estimation the effort (maybe days or hours in) in Planning meeting to assess the story can fix in a sprint and breakdown tasks that can be finished in one day in the Sprint Planning.

Your feedback is very detail and very helpful for me. Now, I understand much more about the difference between Sprint Planning and Backlog refinement. If I still have misunderstood any, please correct me.

Thank you so much. 

Hello @Ian

My question is not about the case that everyone cannot collaborate. It's about the first round of Planning Poker (before everyone explain their estimation number). Because the QC engineer doesn't know the knowledge and skill of the BE engineer so, I understand that even the QC engineer can understand the story very well but he doesn't know how to implement and skill of the BE/FE engineer so that he cannot share the story point well.

Is it correct about the first round of planning poker?

From the second round, the estimation will be impacted by others estimations, the explanation of the others (such as BE/FE engineer. The QC Engineer may still not understand well (Because he has limited knowledge about BE/FE) how to implement the story from BE/FE side. So, maybe he will follow the estimation of the BE/FE engineer). This can make the estimation not correct. I mean this is the anchoring effect.

Do I understand correctly about this?

@Nhan, thank you for your feedback on my feedback. Getting that helps me as much as it does you. 

One thing that I didn't point out and after your response I realize I should.  Remember that when the Development Team plans their Sprint, they are not committing or guaranteeing that everything in the Sprint Backlog will be finished.  They are forecasting the work that they feel they can accomplish in order to support the Sprint Goal.  The Sprint Goal does not have to encompass all of the stories that are pulled into the Sprint Backlog. It is the primary goal that they wish to accomplish and value they want to deliver.  After they start working, new information discovered could affect that decision and should be discussed openly and as it is uncovered (Daily Scrum). The contents of the Sprint Backlog has the potential of changing based on new information discovered or potential available bandwidth towards the end of the Sprint.

There is no "one right way" to do this.  Take everything that all of us suggest and use it as a knowledge base upon which you help your teams arrive at what works best for them. That is the beauty of Scrum being a framework. 

Good luck. You seem to be on the right track and I applaud you for reaching out.  It shows you care about the practices and want to make yourself better.  

Hello @Dainel, Thank you for sharing more about the Sprint Planning. I have a deeper understanding about

Remember that when the Development Team plans their Sprint, they are not committing or guaranteeing that everything in the Sprint Backlog will be finished.  They are forecasting the work that they feel they can accomplish in order to support the Sprint Goal.

Yes, I think this also encourages the Scrum values: Openness, Respect and Self-organize grow naturally in the development team 

My question is not about the case that everyone cannot collaborate. It's about the first round of Planning Poker (before everyone explain their estimation number).

Are you quite sure that the underlying matter is not one of collaboration, as described in the Scrum Guide?

Hello Nhan,

There are plenty of stuff I can't do, but for a lot of them, I will be able to size the required effort, and maybe bring some help.

I will have my car checked by the garage soon. I can't to it myself but I can size the effort at about 2 hours.

I don't know how to make a set of cookies, but I can size the effort of do it at about 1/2 hour + baking time

Hi @Olivier,

I agree with your example 50%. I think you can size your "examples" because you have experience about those stuff at least once. Don't you?

For example, if you take your car to garage to check at the first time and let assume that the car is brand new car with new technology and no one (such as your friends) know about it (I mean you don't have knowledge about it) , I guess you can't size it or you can size it with big variance with no clue. This is not empiricism.

Is my feedback matched with your point? 

(just want to discuss more your example because it is not a knowledge-driven work)

For the rest 50%, I totally agree with you. Your example helps me understand more how we should gather a cross-functional team. Thank you so much.

Hi Ian, 

I would like to discuss the background knowledge limitation of the team members that cause the estimation is not correct. Let assume my team members have no issue about collaboration or sharing knowledge. That is my point. :)

if you take your car to garage to check at the first time and let assume that the car is brand new car with new technology and no one (such as your friends) know about it (I mean you don't have knowledge about it) , I guess you can't size it or you can size it with big variance with no clue. This is not empiricism.

Nhan,

The first time you do anything with little to no knowledge beforehand, it will not reflect Empiricism.   However, the more you perform the task, you should incorporate Empiricism to help you grow and become more proficient at it.

Keep in mind, when we're talking estimation, we're really talking about "guesses".   Some guesses are more educated than others perhaps, but none of it is an exact science!

My suggestion is to allow all Development Team members to estimate, and to facilitate post-estimate discussion around the estimates to promote knowledge-sharing and build size consensus for the item.   The more estimation opportunities and discussions that unfamiliar Development Team members can participate in, the better they will get at such estimations (Empiricism at work!).   

And always keep in mind that such estimations are only best guesses based on the information at hand.

One further point:

What we're estimating/forecasting is what work we think we can get to Done within the period of the Sprint. Each of the skill silos you've described contribute to reaching DOD, so all can contribute to the team's understanding of what they can accomplish in any Sprint.

PS don't forget there's only one role on a Dev team: developer.