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: Advantages to the Scrum team

So what is the Product Backlog Grooming ? The exact details of what the Product Owner and the team does in that meeting varies from team to team, but the broad outline is something like this: These are meeting where the Product Owner, the Scrum Master and the Scrum team attend, with the purpose of the meeting being to go through the User Stories before the Sprint (and the Sprint Planning meeting) where these User Stories need to be planned and estimated. The idea being to ensure that everybody is on the same page with regard to these stories, and there are no major points of confusion or where the team is not clear about a particular story. Well, actually here are some more details of the advantages that accrue to the team if these Product Backlog grooming meetings do happen:
– The team gets an idea (in many cases, more than just an idea, they could already be trying to figure out some high level of detail of these stories by the time that the Sprint Planning has to start) of what the User Stories are going to be for the near future. Doing some enables the team to have more details of the following:
a) Spend a bit of time thinking about these User stories so that the team actually starts understanding about what the User Story is supposed to accomplish and also starts thinking about the design.
b) Some User Stories are different from anything that the team has done before in terms of design, so the team needs to start thinking about the design challenges, and this helps them ensure that they are more prepared during the actual estimation discussion, which increases the level of accuracy of these estimates.
c) Some of these User Stories may have external dependencies. One really cannot expect the Product Owner to have too much detail about these external dependencies, but when the team starts to think about these User Stories during the grooming session, they will be able to understand these external discrepancies and start planning for them way before the Sprint planning meeting.
d) Some of these User stories may be touching on code sections that have not been handled by the current team, and modifying or extending existing code takes time. So, if the team knows about the probable User stories, they can do the research and figure out what is the kind of homework they would need to do and be more confident about the accuracy of their estimates (for example, I was working on a product that had been in the market for 5 releases, and there was always parts of the application that had not been touched for a couple of years or more).
e) There could be internal dependencies that become more clear during the discussions; a consequence of such a discussion could be that the team can work out whether some of the User stories could be dependent on each other or on some other feature, and as a result, some re-prioritization could happen of these User stories. This kind of changing can only happen during these Product Backlog grooming sessions and is not easy to do during the Sprint Planning sessions.

– The back and forth of the Product Backlog grooming sessions also enables the Product Owner to work through the queries of the team, which can lead to much fewer queries later and may also lead to improvement in the User Stories as well as in the understanding of the Product Owner. Else, the worst kind of situation is where the Product Owner is standing in the Sprint Planning session and explaining something to the team, and gets asked some queries for which he/she does not know the answers.

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>