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.

The compromise between having a Product Owner who tries to detail out too much ..

Scrum suffers from problems where you have a Product Owner role that needs to have a person who has understood the role in good detail. In a lot of cases, just transitioning the role from that of a regular Product Management role to that of a Product Owner role takes some amount of getting used to. So, you need to have a Product Owner who is setup to define a level of responsibility where the Product Owner gives enough detail about the feature without trying to get into a lot of detail.
In the regular Waterfall kind of product development methodology, the Product Management team / person defines a great level of detail for all the features and puts these into the Requirement documents. These are then signed off by the customers (in many of the cases), and then explained to the various teams. In turn, the teams then create design documents, test documents, and do a full traceability matrix from the requirements. This ensures that the requirements are adhered to in great detail, and there is no confusion among the implementation team with respect to the requirements.
So, when a member of the Product Management team starts working as a part of the Scrum team, they are used to the level of detail that they already do in the past. Consider the case where the team has a number of features, and the Product Owner looks at the features, and based on their past record, start breaking down the features into how the screens should look like. In the extreme case, the Product Owner will continue on this line and insist that the team should design the screens and dialogs exactly like how the Product Owner wants it to be, right at the beginning of the cycle.
In Scrum, the Product Owner should take the feature / User Story, and define the User Stories / tasks in such a way that they answer the various queries that the users of the product will have. So, when defining user interactions, these are defined in terms of problems that the users will be looking, not in terms of the screens that will be present in the application. This does not mean that the Product Owner will not look at how the UI of the application should like, it’s just that the UI definition should happen near the relevant Sprint; and in fact, the Product Owner should work with the UI designer attached to the team, and work in advance to get concepts of how the screen should look like.
The difference is that the Product Owner should focus on the ease of use of the application, get feedback on how the workflows can be made more user friendly, and so on. And, since the UI is part of the features that are demoed at the end of the Sprint, there can be more feedback that causes a change in the UI that has been designed earlier. The Product Owner should be ready to modify the UI as and when required.
I reviewed what I have written earlier, and it seems to match what our team does, but seems a bit confusing. Can you comment on how your team works ?

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>