Learn Software Development » Prioritization

Discord between the Scrum team and the Product Owner on the feature list priority

ashish — Sun, 16 Oct 2011 19:15:14 +0000

This particular post is more of an opinion rather than a stated part of the process (as far as the discussion that I have had with several Scrum Masters has led me to believe). The Scrum process outlines a role for the Product Owner to define the features of the product, and also to determine the Product Backlog (the prioritization of the features that will be part of the ongoing Sprints). At the same time, the Scrum team is an empowered Product team that needs to take up a much enhanced responsibility for the tasks that make up the features, determining the efforts for the various features, and so on.
So where does the challenge come ? Well, the challenge comes with a team that feels much more empowered, more responsible for the features that go into the product, its feature set versus the competition, the needs of the customer and so more. Teams that have taken on more responsibility typically have people who look at customer forums, who interact with customers to get more in touch with their needs, and similar such measures that bring them closer to the customers and their needs.
This has the potential for sparking a conflict, such as when the Product Owner (based on their own research, contacts with customers, and studies of the market) places a few features as higher priority; and then you have team members, who believe that they know the needs of the customer, coming into some sort of conflict with the Product Owner. Now, you would expect that the Product Owner is the one who decides the priority of features and the details of the feature, but when you get a team to become more responsible for the features, get them in closer touch with customers, then they will start to become much closer to the future vision of the product; so if what the Product Owner is saying does not gel well with them, then there will be some sort of opposition. This opposition can make itself known during the Sprint planning meetings, as well as during the Daily Scrum meeting when the team may have some query on some part of the task, and the approach suggested by the Product Owner may be resisted.
Is this a theoretical position ? No, we have had cases where the managers of the team members have to get involved, in order to better understand the position of the team members, and then counsel (and where required, have a quiet word with the Product Owner). Once in a while, we thought about letting such an open discussion happen, but the thought was that such a discussion would undermine the position of the Product Owner and was not the right step to take.

Problem in Scrum: Looking at technical debt, which will cause more problems as you move ahead ..

ashish — Tue, 04 Oct 2011 14:24:11 +0000

What is technical debt ? Well, I will not try and give a definition for technical debt. Instead, consider that you have 2 approaches to build some great new features. You can do something in a quick way without trying to build a great design, or you can build it the proper way through the required design. Now, if you need to get features done quickly, then trying to build in the proper design and architecture can stretch the possibility of getting the features done in time for the need (say, if the team is under pressure due to market requirements, or due to external stakeholder pressure). In such cases, it is a business need to build the feature done quickly enough, but one of the problems of taking such an approach is that you need to build a structure in order to build more and more features, and as you neglect the design work, building features becomes even more difficult. To put it in another way, in order to save some time in the beginning, you spend more time later. This is what is called technical debt.
In the case of the Scrum process, what I have seen in practice in many teams is the concept that because of the pressures, because of the way that the team seems to work from a Sprint to Sprint, the tendency to think about architectural change can slip by. The whole team is driven through a process whereby the Product Owner defines a set of features, prioritizes them, these are broken down into discrete tasks and estimated and then implemented by the team. There can be a lot of pressure to ensure that the teams are delivering a set of features on a regular basis; further, people are occupied on ensuring that all the features are delivered on time. It can get pretty difficult to insist that architectural tasks are delivered, since there can be a lot of resistance to putting these tasks into the Product Backlog. It would typically need somebody of the stature of an engineering manager to have those discussions with the Product Owner, to explain the need to put in the engineering time for putting in design for building for more features. It can be difficult at times, and in our case, it took us a few months and one round of feature failure to explain the engineering design process in detail to the Product Owner, and now we are in such a condition that the Product Owner totally understands when we push for some architecture work. However, it can take time for the Product Owner to be comfortable with these details.

Scrum – What are some of the important attributes of a successful Product Owner (contd..)

ashish — Tue, 12 Apr 2011 11:41:30 +0000

In the previous post on this topic (attributes of a successful Product Owner), I tried to list some down some of the properties that a successful Scrum Product Owner should have. In this post, I will continue on this line and try to put down some more properties that a Scrum Product Owner should have.
- Since there are 2 types of Backlogs that are in operation during the project, the Product Owner has to understand his / her responsibilities vis-a-vis these 2 backlogs. So, the Product Owner owns and manages the Product Backlog by getting inputs from all the stakeholders, from external industry sources, from end customers, and then prioritize the items in the backlog. However, during the Sprint, it is the Sprint Backlog that counts, which is based on higher items from the Product Backlog. Now, the Sprint Backlog is owned by the Scrum Team and the Product Owner. It is upto the Product Owner to keep the Product Backlog updated while ensuring that the team is focused on the items in the Sprint Backlog.
- The Product Owner has to ensure that the team is shielded to some extent from all the stuff that keeps on happening outside the team. This is even more important when the external stakeholders are not used to the Scrum methodology (as an example, when a senior manager hears that Scrum makes it more easier to change, one of the first reactions that I have seen is that they feel that as soon as something changes in the external environment, they can come in and get the Scrum team to immediately start focusing on that). This shielding is something that the Product Owner does along with the ScrumMaster.
- It is extremely important that the Product Owner understand the customer needs, has spent a fair amount of time working through the requirements, and has all their doubts cleared (I once had a cocky Product Owner who though that he understood everything – big mistake, and in the next letting go, he was let go). Typically, if the Scrum team figures out that their Product Owner is making it up as he moves along, they lose confidence in the Product Owner and will subject the person to a far greater degree of questioning (after all, any rework or change in requirements reflects in the charts, and can lead to inconvenient questions). Having a clear understanding also allows the Product Owner to make the necessary adjustments in priority, and also stand their ground against well-meaning but strong willed external stakeholders who think that they know what needs to be done.

Scrum problem – Making sure that the Product Owner is empowered to take decisions, especially the tough ones

ashish — Tue, 22 Mar 2011 19:08:33 +0000

In a typical organizational structure of a product development organization, the Product Manager has a fairly powerful role. It is the Product Manager who looks at the features that are to make it into the Product. This is done based on various factors such as competitor analysis, various interactions with customers and industry experts, analysis of new technology trends, as well as some imaginative ideas for new features and customer interactions. Now, when you have all these factors, it is difficult to make the exact decision of which feature will have higher priority; and that is where the Product Manager makes the decisions about which feature is most important (or which set of features are the most important). The team depends on the expertise of the Product Manager to take such decisions, given that it is the product manager who is in maximum contact with the customer base and the industry.
When you get to the role of the Product Owner in Scrum, the role envisions a person who represents the customer and the requirements, but also works on close conjunction with the engineering team, typically spending much more time with the team. As a result, because there was no increase in the number of people working on the Product Manager / Product Owner role, we were able to see that there were time issues in terms of being able to spend more time with the customer base and with various industry associations (the time available for this was much less than in the earlier development methodology).
Because of this, in one specific case, we could see that several stakeholders were somewhat hesitant about how much authority to give to the Product Owner, considering him somewhat tainted with a much higher degree of exposure to the development. As a result, a senior Product Manager type of role was also brought into the picture to oversee (more of a consultative nature); but the net result was that there was a resultant image perception that the Product Owner was more relevant to help the Product team and the senior manager was the person who had the clout to take the different decisions. So, when there was a case where the Product Owner decided to decline one of the features that the team had built and wanted to focus the team on another direction (because of feedback from an early set of users), the team actually wanted the senior manager to listen to them and then finally take a decision.
This was a very dangerous situation, since the entire authority of the Product Owner was at risk. We had to ensure that the senior manager declined to listen to the team (since he was deeply involved with the Product Owner, he was convinced about the position of the Product Owner), and there was a reinforcement of the authority of the Product Owner to take the required decisions.

Scrum problem – When the Product Owner does not have enough time for detailing the requirements

ashish — Mon, 21 Mar 2011 18:37:03 +0000

All those who work in a Scrum project are familiar with the concept of the Sprint Planning meeting where the Product Owner works through the various User Stories from the Product Backlog (reading off the prioritized list), details them out enough that the Scrum team can prepare estimates for these, and answers all queries that the team may have (and for complex features, or where there is a domain area that the team may not have much experience with, there can be a lot of queries that the Product Owner should be able to answer).
For all this, there is an expectation that the Product Owner has the details that the team is asking for. We had a case where the area was complex, and the team really went for all the various permutations and combinations. In many of these cases, we would normally ask the team to work through details as they went through the actual design process during the Sprint, but with the expectation that a lot of the basic queries would be answered by the Product Owner, enough that the team felt confidence that the Product Owner had a good grip on the User Story and this was not something that just came up.
So, in this specific case, we found that the Product Owner was so busy, when combined with the fact that the area of the project involved some complex business logic and user interactions; the team was not really happy with the amount of queries that got answered during their interaction with the Product Owner, and this was combined with the fact that the User Story as presented by the Product Owner just did not seem to have a good user flow. When this was clear, and the team also came up and gave up this feedback, there was some concern about whether this could lead to a substandard project being developed; we did some fact finding. When we queries the User Interaction expert, it became pretty clear that the amount of work that we expected would have happened between the Product Owner and the User expert had not happened to the desired level. When the User Story in terms of the simple workflow was shown to the User expert, the expert recommended that it needed some more discussion between the Product Owner and the User expert even before it could be presented to the team.
The next important question was about why the time was not being spent for this pre-Sprint activity. It turned out that the Product Owner was being assigned some additional work for some Product Management activity unrelated to the project (which was not budgeted for), and this was directly impacting the quality of the deliverable by the Product Owner. We got in touch with the overall manager of the Product Management team and got them to re-assign the work (which was for the organization, at a lower priority than the project) and we could see some noticeable improvements even within a couple of weeks.