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 a team member and the Product Owner have a conflict in terms of features

Perception can make a lot of different in terms of group dynamics, even when there has been clarity at the beginning of the cycle. During the training for teams that are going through Scrum, the training focuses on the processes that are part of Scrum. This training will focus on the role of the Product Owner as well as the Scrum team, going through the processes of the Product Backlog (the prioritization of which is done by the Product Owner and who decides the features that are taken up for each Sprint), while the actual execution of the feature development (which includes the breaking down into tasks, estimation and scheduling of the tasks) is done by the Scrum team and they have full authority of how to do this.
However, given the dynamics within the team, there can be cases where this is not so clear-cut and can lead to a lot of scope for a lot of confusion (especially when there should not have been any such confusion). Consider the case where the standard recipe of an experience team and an equally experienced product owner gets modified. You have team members who have been with the product for a long time and you have a product owner who is not so experience with the product (could be an experience product owner who is new to the product / team, or a product owner who is not so experienced overall). In such a case, you would expect the product owner to learn quickly on the job, and at the same time, also learn a lot from the experience of the team. It would make sense for the team members to give suggestions to the product owner and for the product owner to give these serious consideration; but it is the next step where there can be some confusion. In a number of cases, you will find team members who are so passionate and involved with the product that they expect that they know best about the features (well, not at feature level, but at feature workflow level) and expect that their word will be taken.
And this is where I (and other Scrum Masters with whom I have been in contact with) have come across cases where the Product Owner has not been able to withstand the advise of these team members who have good intentions but can be stubborn about pushing what they feel is best. The product owner is the one who has to take the best decision on which features and the Use cases inside the feature, and this needs to be clear to the team (and I repeat, the team can and should give suggestions to the product owner if they feel that there would be an improvement, but the actual decision maker needs to be the product owner). Even though this would be clear to the team during the training sessions, actually getting it can take time, especially when the Product Owner does not have enough steel to ensure that it works this way. In one case, the product owner went with the suggestions even though he felt (a bit diffidently) that the workflow should be different at a specific point during the flow (based on discussions that he had with the marketing team) and this was exactly the same feedback that was obtained from pre-release users. It was modified before release, but turned out to be embarrassing for the Product Owner since the feature workflow was his responsibility.

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>