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: Items can change in the actual Sprint

The idea of a Product Backlog Grooming meeting is that the meeting happens on a regular basis, the meeting allows a discussion between the Product Owner and the Scrum team over features and User Stories that are typically meant for the next couple of Sprints. Consider a Sprint Planning meeting where the Product Owner details the User Stories intended for the ongoing Sprint, and then discusses the details of these along with answering any queries that the team might have; now consider a case where the team asks a question about the feature that the Product Owner has not thought about, or consider another case where the feature is complex technically and trying to get an estimate or breaking down into smaller technical tasks is not possible in the duration of the Sprint Planning meeting. These kind of situations can tend to occur, and that is the reason several teams get into a process called the Product Backlog Grooming where the team discusses features and User Stories with the Product Owner; this discussion can help to ensure that the team and the Product Owner are on the same wavelength with respect to the feature and details of the feature implementation, as well as ensuring that the team spends some time resolving technical issues for those features that are liable to be complex technically, and even prepare estimates for those features where the team can actually prepare an estimate (these estimates help the Product Owner sometimes take a decision about whether the User Story or the feature can actually fit into a Sprint along with the other work planned for the Sprint).
In the Product Backlog Grooming meeting, the features / User Stories that are typically picked up are the ones that would be included in the next couple of Sprints – it does not make sense to spend time discussing features that are not going to be picked up in the near future, and should be seen as a waste of time (and many members of the team will actually see it as a waste of their time – and there will be a percentage of team members who even consider that the Product Backlog Grooming meeting is not something that they should be doing, it is the responsibility of the Product Owner to do the refinement of the User Stories and bring it in a form that is suitable for the Sprint).
In such a case, things can get problematic if there are features discussed in the Backlog Grooming session, effort spent, and then it turns out that those features are not taken for the Sprint. There can be a feeling that all that time was wasted. However, it needs to be clear to the team that the intention is always to take features for discussion that will make it to the Sprint, and only in exceptional circumstances would such a case happen; and that decision is the discretion of the Product Owner. The Product Owner may realize that there are other more important features that have come up, maybe because of competition analysis, or a change in the industry, or a change in the objectives of the organization and the product and these kind of factors need to be analyzed by the Product Owner. Such kind of factors can cause a different set of features to be taken in the Sprint, but equally important, the team should have confidence in the Product Owner that a change in the feature was only done because of an exceptional factor.

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>