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: Working to ensure that the Product Owner understands Scrum and the role

The Product Owner is one of the critical people in Scrum. The role is similar to the role of the Product Manager in other development models, but the Product Owner for a team that is working using Scrum does entail a fair amount of training to understand the role correctly. I remember a previous team where we were wrestling with how to improve the efficiency and productivity of our team, and were evaluating the experience of a team that was sitting right next to ours. The quick couple hour discussion and Q&A with the Scrum Master and a senior guy from that team provided our team with the inputs required to start considering a change in the development model we were using, moving towards using Scrum. However, the Product Manager did not really take much of a part in these discussions, and it turned out that the Product Owner was very skittish. We had a discussion with the Product Owner and realized that he was very apprehensive about this change, since the feedback he had got from some initial review of Scrum processes was that he would suddenly land up in a situation where the team was responsible for making many of the decisions, and the role of managers in the earlier methodology was changed to being more of coaches and looking at the organizational needs of their team members. Based on this discussion, it was clear that the Product Owner had heard something which was partly true, but there were major problems in his understanding.
So, the major impetus in our case was that along with some intensive training to the team members about the usage of Scrum, we had to also ensure that we had a great training ready for the Product Owner, and it turned out that we did not have something that the Product Owner could call a transition from the Waterfall MS Project based plan to a Product and Sprint backlog situation, and there was also a lot of fear from the Product Owner about the level of detail that the Product Owner was required to provide to the team, which was a level that was not uniformly used elsewhere. It seemed like a lot of hard work; but this was something that we were able to also handle. A Product Owner from the neighboring team was called in and had a discussion with the Product Owner, with the main emphasis being that the Scrum based methodology actually provided a lot of details to the Product Owner about the stage of completion of features, and the Product Owner could even play with parts of or the complete feature at the end of the Sprint cycle; when you combine this with the fact that the Product Owner could have an incredible level of details on the feature by defining exactly the tasks that are required to be done, as well as the ones that could be dropped because of prioritization issues, it started turning out to be advantageous to the Product Owner. The Product Owner was apprehensive about the number of meetings due to the Daily Scrum meeting, and the explanation about the meeting and presence of the Product Owner being optional also settled this doubt (the Product Owner would eventually the meeting once every few days rather than on a daily basis).

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>