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.

Scrum – what happens when the Product Owner is over-worked ? (contd..)

In the last couple of posts (work load for the Product Owner), I have been writing about the problems faced by the Product Owner. These relate to a case when there is too much work load on the product owner; further, there can be a number of factors that control the load on a Product Owner (these can depend on the complexity of the project, the domain knowledge of the team, and whether the team is new to Scrum or is an experienced team). In this post, I will take a case when the Product Owner is getting over-worked because he / she does not have the total support of the team.
It is normally not the case that the Product Owner is denied support by the team willfully, it being more likely that the support problems arise because of a confusion regarding the roles and responsibility of the team vs. the Product Owner. In the classic roles, a Product Manager defines the product requirements to a great level of detail, including working with the Usability Designers to get the exact UI of the application. These are fairly comprehensive documents, which translate into further documents such as design documents, etc, forming a huge traceability matrix for complicated products. The team is locked early on into detailed documents, which are very difficult to modify later if some of the requirements for the product need to be changed because of market requirements.
In the case of Scrum, the need for writing such detailed requirements is not valid any more. With the help of a team that is much more empowered, with the concept of having a system whereby the requirements can keep on changing over a period of time, the Product Owner does not need to write such detailed and exacting requirements anymore. The Product Owner typically defines the User Stories in terms of how the user would see the workflow, and has to make sure that the User Story captures the workflow of the users. The User Story typically does not get into minute level details, nor does it define the type of technology to be used. However, it is expected that the Scrum team gets into more details, and if they have some amount of confusion, they can ask the Product Owner for more details. This is how the Scrum teams work in a smooth manner.
However, it get problematic where the team is somewhat new to Scrum, or has got into the expectation that they will be given a detailed set of requirements similar to what has been used in the Waterfall development methodology. If the team is not given sufficient training or feedback to change this, then this is the way things will work, and the amount of load that it adds onto the plate of the Product Owner is fairly significant, which in turn can affect the efficiency of the Scrum team (since if the Product Owner is inefficient, it will impact the whole Scrum team).
What needs to be done ? Well, if the Scrum Master is able to identify that the team seems to be getting into the mode of adding more detailed requirements onto the plate of the Product Owner, corrective action needs to happen, and fairly quickly. The team needs to be shaken out their current mindset.

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>