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: Feedback being looped into refining User Stories

The topic seen above may seem a bit dense, but it just defines the technique that needs to be an essential part of any effort to do Product Backlog Grooming. When you go in for reading about Grooming, it seems like the perfect way to fine-tune the Product Backlog so that when it comes time to do the Sprint Planning, everything is in perfect order. However, it is also seen as a problem in the sense that such meetings have to happen during the regular Sprint work, which means that the team needs to take time out from their regular work on tasks and spend time on the Grooming process; and even though it seems fine to say that this will make things easier, their can be resistance from team members. So what is to be done ? Well, one of the primary objectives of your Grooming session is to make it as effective as possible, so that one complaint that the team cannot have about the Grooming session is that it seems like a waste of time. This post will reflect on one of those practices, namely about how to ensure that you are weeding out User Stories that are not really needed by customers or are potentially important features.
When the Product Backlog is opened to everybody, you can get a potential huge number of User Stories that are there in the system; and having such a huge list does not mean that you should discourage people from contributing User Stories. People involved with the product can suggest User Stories that have been overlooked by others, or can suggest modifications that will enhance the value of features in the product. And you can have enthusiastic team members and others from outside the team who suggest a number of such User Stories, and together, these can increase the number of User Stories present in the system to a large number. Realistically, you can only do a smaller number of User Stories, and part of the process of doing the Product Backlog Grooming is to reduce the number of such User Stories by weeding out those that are not really going to add value or fit into the future direction of the product (for example, if you product is much more geared towards integration with social networking, you might not put too much emphasis into enhancing the CD/DVD workflows in the product). Towards this end, you need to ensure that you collect a number of different feedback for this grooming process.
When you release a product, or when you work with pre-release users, or when you work on usability testing, or other such occasions where you can get feedback on current features or feedback about missing features, it is critical to collect such feedback. The initial step is where the Product Owner looks at such feedback, does an initial analysis about the features that important to users, or the features that would help drive sales and customer acceptance, and then compares this with the User Stories that are already there in the system and does some cutting right away (and this can be brutal in some sense, since the Product Owner might be gung-ho about some new features but the users indicate that those features are not really important for them). However, this is where things can get a bit complex. The Product Owner does need to remember that everybody has some sort of bias, including the Product Owner, and if there are some significant User stories that are getting cut, it can be pretty useful to have an open discussion about this in the Product Backlog Grooming meeting. The team might come up with some new points on this, or suggest some improvements that may enhance the User story, but the end decision remains with the Product Owner. The end result is a slimmer Product Backlog, with features being trimmed that do not fit in, even though some of them may be great features in their own way.

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>