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 – Removing team suggested features

One of the primary items in the Product Backlog Grooming is about having a process whereby the Product Owner and the Scrum team can get together on a regular basis for discussing the items in the Product Backlog and do some of the following:
– Removes items that don’t seem relevant
– Refines items based on outside information such as changed technical circumstances or industry developments
– Proposed technical exploration for items that are technically complex
– Looks for estimation of those tasks where the estimation can be difficult, so that such estimates are accurate when presented in the Sprint Planning meeting
All of these promise to make a much smoother Sprint Planning meeting, but there are several problems that are also apparent in such a process, or atleast there are concerns that need to be handled.

A number of these relate to a feeling where the contributors to the Product Backlog feel stifled. There can be a number of contributors to the Product Backlog, with some of them being the Product Owner, features from competitor analysis, contribution from the team members (who have had a lot of experience with the product and the customers workflow). The problem is also increased because a number of the features that come in from the team members may not be large features, but are more improvements that could make the product more efficient, or remove some shortcomings, and so on. Many of such improvements can do a lot for the product in terms of optimizing it for customer workflows, making it faster, and so on.

However, a number of such features are not really significant when you look in terms of attractiveness of rich features. After all, when you can have bright shiny new features, what is the attractiveness of feature improvements, and hence the possibility of such features not being taken is low. After all, as a matter of reality, there are limited resources available in every Sprint, and there is a lot of work to be done; further, when you look at a product in terms of internal and external stakeholders, a lot of focus is in terms of the new features that are getting added to the product.

Now, if this happens again and again, then you will find that the contributors from the team will slowly start getting disillusioned. After all, when people see that their features are not so well appreciated and are not included into the product not because there was something wrong with them, but because they are not so shiny or are related to product improvement rather than new features. There is a need to have innovation within the product team, because the team can generate a number of improvements and if this dies down because the team feels that their features are getting rejected during the Product Backlog Grooming, then it is not a desirable state of affairs. There needs to be more careful attention paid to this by the Product Owner.

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>