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 ?

When we were going into the Scrum model for the first time, and had the initial indoctrination. When some of the more senior management team read the first few sets of slides that talked about the development model, the concept of the team being much more involved in decision making and the fine level of detail, one of the byproducts was the thought that “Do we need the same amount of management resources as was there earlier ?” Specifically, the discussion was about the Product Management kind of area, from where the Product Owner for the Scrum project would belong. It was felt that with the team being more involved at a detailed level in terms of understanding the feature / user stories, breaking down the features into stories, estimating these, and so on, the need for a Product Owner would be more at the time of defining the User stories and explaining these to the team (the Sprint Planning time). As a result, was there a possibility of having lesser number of Product Owners for the overall project (we had a structure whereby there were a few products under the same business unit, and so there were normally 4-5 Product Managers / product Owners) ? On first thoughts, it seemed that this may be possible.
In our current system of Waterfall, we had Product Managers being utilized throughout the cycle, and they would remain busy throughout the cycle. We had tried to optimize the extent to which the Product Manager would be called through the cycle, but did not reach a good solution anytime, and after some time, had accepted that we would continue to have the current number of PM’s. So, when we moved to Scrum, there was a feeling that with a more efficient cycle, and with a more ’empowered team’, there would not be a need for so many PM’s; in fact, you could do with lesser. Among the middle management layer, there was some cynicism over this thought, since none of us really saw Scrum as a silver bullet that would fix everything – we would be happy if we got a more predictable cycle where we could show something to customers at periods, and not have the bug avalanche at the end.
But, senior management thoughts being what they were, the number of Product Managers was reduced by 2, and the Scrum cycle was started.
However, it soon became apparent that we seemed to have over-extended ourselves. With the number of Scrum teams that had been formed, it seemed to be a logistical issue to get the Sprint planning meetings. We also found that in the past, the Product Managers were normally fully aware of the details of the features and seemed to be very well prepared, but now, there would be cases when they were not able to answer many of the queries. When asked about this, a significant percentage of the answers complained about too much work being put on them. This got to such a big problem that the effectiveness of the team started getting reduced and in one of the Sprints, we found that the amount of work done was much less than desired, a lot of which could be traced to many of the team members not having full details of what needed to be done, or were conveyed something that was not fully accurate.
To be contd ..

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>