A challenging situation in a grooming session

Vask,

I am assuming that the 2 architects are not members of the Scrum Team.   If that is the case, the architects should not be in a position to either ask the team to provide documentation (different approaches), or insert themselves between the PO and the Development Team.

To answer your questions (keeping in mind that all I can provide is observations and suggestions based on the information provided:

1. What was the goal of the meeting?   Is the "what" of the initiative well-understood by both the PO and the Development Team?   If not, there is no value in discussing the "how".   If the "what" is clear, then what is preventing the Development Team from relatively sizing the item and taking responsibility for identifying the best solution?
2. I have worked in environments where architect-level individuals "floated" from team to team, providing guidance to teams and being available to respond o any team-based queries around potential solutions.  In mt opinion, non-team members should not drive any part of the refinement process, as that derails the Development Teams' ability to self-manage around potential solutions.
3. I am in favor of always having the entire team participate in refinement, as that cuts down on the need to re-communicate any details; however, I have served teams that have refined with only part of the Development Team, and they relied upon those attendees to bring the rest of the team up to speed.   Whatever approach works best for the team.
4. I would defer completely to the Development Team.   They are the ones doing the work, they are the ones providing the estimate, they need to be the ones making the determination that they know enough about an item that it can be accepted and delivered in an upcoming sprint.
5. you can take from my suggestions, or leave it up to the Development Team to decide.   I would personally have a strong preference to limit any refinement sessions to only the Development Team and the Product Owner.

Respect time-boxing.

Respect that an invited party most likely gave advice in good faith.

Respect that the Development Team are in the driver’s seat when refining their work.

Hi Vask,

I agree with Timothy except last comments which is "I would personally have a strong preference to limit any refinement sessions to only the Development Team and the Product Owner." 

Particularly in grooming sessions PO and Dev. Team need some Subject Matter Experts' support so that to understand and explain what are the needs and effects of them.  

“As it turned out, the story wasn't just a story but actually a feature. The whole team was involved in the session and two architects as well. The discussions lead to two approaches, and the architect left the meeting by asking the tech lead to do a write of both the approaches and ask the user.” There is nothing wrong with the 1st part but the user will not know what the best approach is nor the PO. The team should decide which approach works best in consultation with the architect but they decide the technical approach.

"We time-boxed the discussion but the meeting ran over. The team thinks that they need to ask questions and can't just decide an approach just for the sake of it". Correct they should not just starting building if they are still that confused. You need to coach them that they are self-empowered to make these decisions as long as they are meeting architected guidelines if you have them.They need to ask all the questions they need to make the right decisions. You need to facilitate and coach that.

"The emotions ran high" They will, and they should nothing wrong with that.

"the team felt that the architect didn't contribute but made things more confused and the product owner thinks that the team didn't do a good job." The team does not feel empowered to make the right decision, you have to change that either by your own actions or help from management. The PO can be confused with the technical approach they should not have a say under normal circumstances. What the PO should be concerned about is the value you produce with the complicated feature at the end of a sprint. I sniff what’s going on here is and it’s normal in a complex environment.

1. What should have been done and what shouldn't have been done in this meeting? Nothing maybe just sends out an agenda before each meeting.

2. What should we expect from the architect? That depends but short answer if for him to be a consultant to the team.

3. Is it ok to have the whole team participate? Absolutely yes.

4. How to reach a conclusion? The team needs to decide the approach and be able to explain to the architect and the PO why. They have to feel empowered to do so.

5. What's the best method to run this type of meetings? Any that you choose old terminology would be a JAD session. “Joint Application Design”. You just have to hash it out and make a decision.

Sounds like you got stuck defining a solution instead of refining the requirement and ensuring that product backlog item will derive value for the business. So, when you hit a conflict between two possible paths for the solution the team got confused because now they were being forced to make a decision about the solution in order to provide an estimate...a decision that might be sub-optimal and may no longer be valid by the time the team actually picks up that work.

What I think you need to is this:

• You need your team to define a set of guiding principles for your software architecture.

Clearly these aren't set in stone, but something the team will revisit intermittently, but what this allows you to do is:

1. Instead of debating architectural solutions and the merits, risks, and potential complexity thereof and trying to then estimate based on that the team KNOWS what they should be practicing and when it comes to refinement they will estimate based on the complexity of following their guiding principles (you can negotiate the intricacies and alternative options once you actually start working on the story and discover gaps in your logic or understanding.)
   
    
2. It helps to mitigate or at least increase the transparency of technical debt. I suspect that what you're ultimately doing is trying to decide between a faster sub-optimal option and a more complex option that might be stretching your team's skills. Adhering to your principles helps you make sure you're doing the right thing rather than cutting corners, which will cost you more later.
   
    
3. It keeps the team focused on their goals and constantly improving and iterating, rather than constantly cutting corners and letting software stagnate because of the pressure to deliver, or at least when you do decide to choose the "quick" solution it's done as a means of ensuring that you deliver to the Sprint Goal rather than because that's what you estimated.
   
    

In all of this, you do need to be honest about your principles. If you say you should be using a microservice-based application deploying in containers, but you simply don't have a way to put that in place, that should NOT be one of your principles. Instead you can set that as one of your team's goals as something to work towards in the future. You should also make sure that these principles tie back into how they add value to the consumer.

As for your specific questions, I agree with Dan's answers and would just be rehashing.