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.

Problems when the Product Owner is not able to specify a priority list of requirements

In many posts in the past, we have talked about one of the primary responsibilities for the Product Owner (Product Management) being the need to maintain a Product Backlog, that has all the requirements, converted into User Stories, in prioritized order. And this is an area where there are a lot of issues. We have had cases where the Product Management has outright refused to define a list of requirements in a prioritized order. This is even more so in the case of Product Owners who are not used to the Scrum based process of development, and who believe that their old methods require very little tweaking (actually, in some cases, I believe that the Product Owners believed that the only changes that are required are in the way that the development team does its work and that there is no change in the way that the Product Owner needs to work). And this was after a full round of training, including a specific section on the Product Owner responsibilities. It is only the Product Owners who have some experience with Scrum, and are used to the definition of their roles who are more comfortable with the various requests on them.
So what happens ? In the traditional model, the Product Manager would have defined a list of features (based on competitor analysis, customer sessions, and so on) and then did the hard work of categorizing these features into priorities. In our case, we would have the following baskets, Priority 1 (P1), Priority 2 (P2), Priority 3 (P3), and beyond these, there was not much point in defining the feature set since we would never get beyond these priorities when the adoption of the feature set was done. In actual execution, since we had dmultiple engineers and QE, we would assign each of the P1 features to one of these engineers / QE, and they would start work on each of these P1 features first.
However, when we did our training on Scrum, and then started work using the Scrum based model, getting a Product Backlog proved to be fairly difficult. It was getting difficult to ensure that the Product Owner had actually defined a priority for each feature (not just lumping them into priority baskets); and for the first 2 Sprints, we literally had to force the Product Owner to assign the priority for the feature set and get each User Story to have its own priority. The Product Owner did this work, but very unwillingly; it was only when the Product Owner was able to see after a few Sprints that all the important features were getting done that we got a convert in the form of the Product owner. Not having the proper priority was having an impact on the team, since they started seeing that we were willing to take shortcuts with the Scrum process and did not understand why the Product Owner was not able to get the priority in place.

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>