During the last PI planning, at the first break-out session, I observed passive behavior in the Team. The collaboration quality between the Team members and the Product Owner was not smooth and showed some dysfunctions in particular:
- The Product Owner was not challenged on the features on hand
- The discussions in the Team were monopolized by some Team members
- Some Team members were totally silent
- The Product Owner was frustrated of the situation and anxious about the Team’s understanding of the features and the underlying stories.
I used to face this collaboration problem and to find a solution on the spot. I was driven by the expectations of the Product Owner:
- Product Owner would like to learn about the Team dynamics and the team problem solving interactions
- Product Owner would like to get all the Team members engaged in the refinement process
- Product Owner would like to have Team member committed to the groomed feature or story
- Product Owner would like to have the Team members aligned on the feature breakdown and the user story description
I thought about the Liberating Structures as building blocks that I can use to solve the problem in hands. And here, YAGY saw the light!
In this blog I will share wit you the first two collaboration structures I used with the Team in order to meet the expectations of the Product Owner.
Build a common understating around a complex story with 1-2-4-ALL:
The first method I suggested is based on the 1-2-4-all structure. The step by step description is depicted hereafter:
( 2 min )The Product Owner reads the story and briefly explains it with the acceptance criteria if available.
( 1 min ) Each Team member takes one minute to self reflect on the story according to its complexity. The Team member can note any attention point or question for clarification.
( 2 min ) Each Developer will pair with either QA (Quality Assurance aka Testing) Team member or Business Analyst (Functional Subject Matter Expert) Team member. If not possible then pair with another developer. Then the pair will exchange their understanding and try to answer raised questions and analyse attention points together if possible.
( 4 min ) Now each pair will chose another pair to form a group of four. Within each group, the Team members will try t exchange on the topic and try to answer questions and attention points if possible.
( 2 min ) Now Each group will share with the the other groups and the Product Owner the unanswered questions if any and to share the attention points they have. The Product Owner will then try to answer the questions and to reflect on the attention points.
The ALL step took five additional minutes, so 7 minutes in total.
Break down a feature into User Stories with Wise Crowds:
The second method I suggested is based on the Wise Crowds structure. The step by step description is depicted hereafter:
( 2 min ) The Product Owner presents the feature in two minutes. With the information available on the acceptance criteria and the business impact.
( 1 min) The Team have 1 minute time window to ask questions to clarify some acronyms or unclear sentences that might impact the global understanding of the feature.
(10 min) The Team discuss the feature and do the breakdown in to User Stories. No structure was suggested in this version. However I suggested to the Team to nominate two roles: a time keeper and a recorder. The time keeper will help the Team focus and deliver on time and the recorder will help capture the discussions and makes the discussed User Stories visible to all Team members on the whiteboard.
( 5 min ) The Team will nominate one person to present the User Stories to the Product Owner with the list of questions and attention points. The Product Owner will then review the User Stories and together with the Team try to refine where there is a need.
Retrospective on Using these new Collaboration Formats for Refinement:
In the next blog in this series I will share with you my reflection on the refinement process through the Iterations. And other YAGY building blocks. Keep Tuned!
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.