Categories

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 – making attendance voluntary for team members

I have put in a number of previous posts that talk about Backlog Product Grooming, but this post is different. Some of the feedback I have received talks about a process where the Backlog Product Grooming is not a meeting where the entire Scrum team attends, instead attendance is voluntary. The major difference in this process is where the Product Owner sets meetings for discussing specific features / User stories and lets the team know about these meetings. The team members who are interested in these User Stories will make time for these meetings, instead of getting all the team members to attend. One of the perennial complaints of many Scrum teams is about these Backlog Product Grooming meetings takes up time during the Sprint where they are supposed to be working on their tasks (and this can even happen for teams which have seen the advantage of having such meetings so as to make the Sprint planning much smoother); this is also related to the grievance that setting a Product Backlog Grooming meeting dilutes the responsibility of the Product Owners towards User Stories.
So what happens ? Well, during these voluntary meetings (in some cases, depending on the relationships within the team, the Product Owner could request some team members to come who have information or are otherwise important and who have not turned up for the meeting), the Product Owner goes through the User Stories that have been processed by the Product Owner to the extent to which the Product Owner could work on the User story. The meeting does act like a discussion of the various issues related to the User Story, with some of these items coming up:
– Team members with experience of the functionality point out improvements in the User Story and these can be discussed
– Team members can point out technical issues with some of the proposed functionality (my experience has been that in some cases, the Product Owner tends to simplify the technical solution while the engineering folks go the other way)
– Team members can also give a quick estimate (which will not be held against them during the Sprint Planning, but there is an expectation that they have spent the required effort to ensure that the estimate is as accurate as can be)
As this concept progresses, team members will start to appreciate the advantages of such a meeting and make time to attend (that remains the hope if all logical thinking people 🙂 ); but what it does also do is to ensure that the team members now have a shared responsibility for the User story, and if there are queries from other team members in the Sprint Planning meeting, the attendee team members can step up and answer some of the questions (and in many cases, you will have an objector who likes to point out various flaws in proposals, and team members trying to answer queries can help ensure that some of that is controlled and lead to a smoother Sprint planning process).
Of course, it can also happen that the Product Owner does not get people showing up for these User Story discussion meetings and starts to conclude that such a process does not work, in which case either the team need to do some more discussions of the advantages of such an approach, or there needs to be efforts to get another process which works.

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>