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 – Ensuring that the Product Owner has put adequate effort

The process of Product Backlog Grooming is supposed to act like the initial part of the Sprint Planing meeting, in the sense that it gets the Product Owner and the team on the same page on User Stories that are planned for the next couple of Sprints and helps to ensure that the actual Sprint Planning meetings run well. However, not everything runs this well. In a number of cases, teams have talked about their expectations from the process. Since the team has to spend time during Sprints for these meetings (besides other subsequent work related to this process, which includes investigations and estimations), they have certain expectations before the meetings can start.
One of the primary expectations is about the work done by the Product Owner before the commencement of the Product Backlog Grooming meeting. I have heard criticisms from Scrum teams where they have gone into these meetings to find that the Product Owner has knowledge of the overall feature but has not really tried to spend time on workflows, on user flows, and on User Stories. In such cases, teams can do this once or twice, but pretty quickly the team will start to feel that this was work that the Product Owner should have done and their time is being wasted. Once the team starts to feel this way, the meetings will become less and less useful; but it is not only related to their feelings. If they have to almost start from scratch on User Stories (or try to modify less than prepared User Stories), it is going to take a lot of time (probably too much time, and certainly will over-shoot the time that would have been scheduled for these meetings).
So, how do you prevent this from happening ? Well, a simple and smart way is to define a set of acceptance criteria before a feature can be discussed during the Product Backlog meeting and the team can see progress on these acceptance criteria before the meeting. So, as an example, the team can discuss with the Product Owner and come up with a definition of what is acceptance and can be verified before the meeting; and then, only those features can be taken up during the Backlog discussion meeting where these set of criteria have been fulfilled.
These may sound a bit harsh, but if a Product Owner is indeed spending the required amount of time on preparing the User Stories for such discussion, then there would not even be the need for such kind of acceptance criteria. In many cases, team members feel that it is the primary responsibility of the Product Owner to refine the User Stories, and even if they are involved in such discussions, it should not take away from the fact that the Product Owner would need to do his end of the work before the meeting (else they may even stop coming to such meetings since they would start to feel that their time is being taken for granted).

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>