A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Product Backlog Grooming: Team not comfortable being part of analyzing User Stories

The Product Backlog Grooming process, if done correctly, can help to keep the Product Backlog lean and fully ready for the Sprint Planning meeting and ensure that the team and Product Owner have the same understanding of the User Stories. This can help to ensure that the efficiency and productivity of the team is high. However, it is not easy for the team to reach such a point. There is a lot of resistance in getting there, and the team may take some time to understand why they need to be a part of such a process; since after all, their time is also involved. The basic understanding of many members of the team is that anything to deal with adding / editing / refining the User Stories is the job of the Product Owner, and there is no need for the team to get involved with all this; in fact more vocal members of the team have been known to state that this should be done by the Product Owner and there is no need to waste the time of the team for this.
However, if you have read some of the previous posts on Product Backlog Grooming, you will realize that there are a number of benefits to the entire team if they do the Product Backlog Grooming effectively. It still works on the basis that the Product Owner has the primary responsibility for ensuring that the User stories are relevant, that the older ones that are obviously not relevant are removed and so on, but it also works with the understanding the team is more involved in the User Stories refining process than being on a stand-off basis.
The primary benefit (based on discussion with many teams that are actually doing such a process) is that the team gets a say in the process of refining the User Stories, and of working through the details with the Product Owner so that there is a much clearer understanding of what the User Story is about, what are some of the more difficult queries regarding these User Stories and so on. Additionally, this process gives the team a chance to explore and maybe have a plan to resolve some of the technical difficulties that may come about in some of the User Stories and also helps in deriving a rough (the level of accuracy in the estimation depends on the time that the team wants to spend on this estimation process) approximation of the overall estimation for the User story. All of these details work to ensure that the Sprint Planning process is clearer, with less doubts between the team and the Product Owner, the estimates that are derived by the team during the process are more likely to have a higher degree of accuracy.
Now all of this may be theoretically known to the team, but in order to avoid resistance from the team, more discussion may be needed in this regard, and the team may take it one step at a time, going in for less discussion in the initial meetings and a reaching a balance that is comfortable for the team and the Product Manager as more such meetings happen.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>