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.

Scrum – What can happen when your Product Owner is a big picture guy and really does not get into details

If your Scrum team is in such a situation, you are in fairly big trouble. We had a case come to us from another organization where the Scrum team was in deep trouble and was starting to raise a number of issues – over their first few Sprints, it was found that the team was not able to meet their estimates for a large chunk of their work; it was hard to compare their velocity and capacity, and overall, their larger stakeholders were starting to raise issues about the performance of the team, and the Product Owner was adding to the din.
What was happening was that the Product Owner was another of those people who did not really get into the Scrum training Program, who felt that it was his job to get the overall industry scenario and what the customers wanted, but a lot of this was at a high level. The Product Owner was very well recognized in the industry and was well known for his connection to the customers, and for being able to stay ahead of competitors in terms of what the customers wanted.
However, the biggest problem with this guy was in terms of his abilities of directing working with an engineering team in a Scrum model. So, the Product Owner did not really get into details of the User Workflow, the different scenarios that come in when you start working out the actual different workflows that can happen. If you were to ask the Product Owner about what would happen in Scenario 1 vs. Scenario 2, and in other scenarios, he would getting blank, and expressing statements that he is there for the big picture, not for getting into these details.
What made all this problematic was the fact that the Product Owner would take this same attitude in the Sprint Planning meeting. When there came a time to explain the details of the User Stories and answer questions so that the Scrum team could estimate, the Product Owner would claim that he had not worked through the details (and the Usability Designer had the same attitude since the Product Owner would not have done the required amount of working through the details).
As a result, the team was finding it very hard to do an estimation of the tasks, and as a result, at the end of every Sprint, the team would find that their progress was not predictable, that tasks that were supposed to be done in the Sprint were not getting done, and so on. After a couple of Sprints, the team decided that this was badly affecting their effectiveness, and took this up with the Scrum Master, and wanted to see some action. It was hard for the Scrum Master to take some action, since this was a senior Product Owner; but since this affecting the team, something needed to be done. As a result, this was taken up with the stakeholders, and finally decided that an Associate Product Owner was needed to actually work between the Product owner and the Scrum engineering team to break up the User Stories into tasks, and provide the details that the team needed.

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>