Shivani is the Scrum Master of for the Palomar team. She approaches you, the Agile coach, with a situation she is facing with the Backlog Refinement.
Palomar team has scheduled regular Backlog Refinement meetings for couple hours on their Fridays. These are not sufficient and at times more meeting(s) are scheduled. In spite of this a good amount of time is taken up for refining stories in the Sprint Planning meeting too.
The stories are taking a long time to refine. The initial discussions are very intense though restricted to a some of the team. The rest of the team just listens into the discussions, with occasional participation. After the initial discussions the pace of the refinement is slightly better, but overall there is a lot of time going towards Backlog Refinement.
Shivani feels that the Backlog Refinement meetings are not effective – taking inordinate time. Some of the team members, have shared the feedback along the same lines, one on one. One of them said, these meetings were like the Tower of Babel, people speaking at cross purposes and arguing without attention to converge fast and build a great product. In the recent sprint the team was not able to complete all the stories they had planned. During the retrospective the possible causes that emerged was too much time in Backlog Refinement and inadequate Sprint Planning.
The question on top of Shivani’s mind – do all team members have to participate in the Backlog Refinement?
What would be your answer and possible approaches to make Backlog Refinement effective.
Solution:
There is an adage that Backlog Refinement is a never ending process, one keeps refining the item as the team takes the story to the Done state. Nevertheless there should an approach that gets the best outcome with the least effort.
One of the assumptions the teams make is – it is necessary to have the entire team participate in the Backlog Refinement meeting. Definitely this is a must, if we look at the intent behind it – it is for the team members to have a clear understanding of the user story / product backlog item. The understanding is preferably gained in discussions over written documentation, as it is more effective.
There is another assumption, that is often overlooked – the stories or the product backlog items are reasonably well formed prior to the Backlog Refinement. In the case of this team, this was lacking. A good practice that has emerged is to have a status of the story as “Ready for the Team” or “Draft”. This indicates that the story is in a reasonable form and the team can then understand, refine and size it in a dialogue with the Product Owner, to get the story to the “Definition of Ready” state.
To get the story to “Ready for the Team” or “Draft” state, the entire team need not participate. It could be the PO, SME and other stakeholders, with the SM participating as needed. Bringing in this change helped the team to make the Backlog Refinement effective and enjoyable.
2 Responses
While the solution is simple, its implementation will be tough since the business would not easily sponsor them. While it is a good idea to write all technical debt stories, generally, there will not be any Product Owner who likes to own and accept since the PO comes with business mindset. These kind of work is pushed by external team (not the scrum team). Generally, these is a lack of ownership of these stories and pushed by external teams. I am purposefully, I am not the solution this gap in this comment. Want to hear from others.
I agree Guru. The reason why i mentioned this as a Dilemma for the Engineering manager is do we handle only the low hanging fruits and run with it, or would you work for a harder and more difficult transformation of creation of a working pipeline.
I know one manager I have interacted made the call and felt the next 6 months extremely hard to convince and influence different stakeholders. This is easier to accept while you are doing a transformation.