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.

Some problems with Product Backlog Grooming ..

I have been writing a number of posts about the advantages of Backlog Product Grooming, including the advantages it presents for ensuring that the Sprint Planning meeting is far smoother. However, there is a flip side to the story, and there are a number of reasons why the Product Backlog meeting can actually be troublesome for teams, especially when the team is not convinced about the need for doing the meeting. Here are some reasons about why the meeting could end up being painful, and if teams are wanting to do the Backlog meeting, they need to ensure that they have solutions to these and other problems rather than rushing directly into this meeting (each of these points can have multiple ways of solving, and trying to provide resolution would make this post far too long):
– It’s yet another meeting. There are multiple meetings that the team needs to attend such as the Daily Scrum meeting (and any spin off meetings to resolve issues raised during the Daily Scrum), the Sprint opening and closing meetings, and so on. And when the Sprint duration is less than 3 weeks, it just seems to be perceived that these meetings take up too much time, which can make the team uncomfortable (they tend to associate a meeting as being different from actual work); now when you add periodic Product Backlog Grooming meetings, it can only cause issues.
– They perceive this task of getting into some detail to the User Stories as something that needs to be owned by the Product Owner and the designer and it can happen quite often that they believe that this is not something for the team before the Sprint Planning meeting.
– Different skill levels in the team, especially when it relates to Scrum. So when there is a discussion about designing and refining User Stories, experienced team members can do it much quicker than newer team members and in turn this can cause frustration about the slow pace of work in this area.
– In many areas, the Product Owner has a much better functional understanding of the product and the customer workflows (not the ones in the existing product), and the team cannot match the level of understanding of the Product Owner in this short time, and this can cause frustration since this whole process takes time.
– The team can feel that they are wasting time, that they are supposed to be doing the work allocated to them in the current Sprint rather than the Backlog Grooming meeting (this can be helped if the time set for the Backlog meeting is accounted for in a task in the Sprint).
– Even the tool can cause frustration. The Product Owner could be finding problems in using the tool and this would cause the pace of progress to be slow, which can also be frustrating for the team.
– Time limits for the meeting. Since a Backlog meeting can be important, many times I have seen teams extending these meetings to ensure that all the items that were needed have been discussed, but extended meetings can be the source of great frustration to many members of the team.

There can be numerous other reasons why the Product Backlog meeting can be problematic for teams; teams need to ensure that they understand the benefits and advantages of the meeting and only then start doing such a meeting.

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>