There have been some posts in the past that talked about Product Backlog Grooming, and this post is a continuation of the articles on this subject. This post will cover some of the advantages that the Product Owner gets when the team is actively involved in a periodic Product Backlog Grooming with the Product Owner with the intention of refining the User stories planned for the next Sprint. Here goes:
- One of the biggest problems that the Product Owner runs into during the Sprint Planning is when there are some tough queries from the team as the Product Owner is explaining the User stories. There have been occasions when the team has pointed out very valid issues during this discussion that the Product Owner had not visualized, which leads to an uncomfortable situation; in some cases, it was impossible to modify the User story at that point of time, which meant that the tasks had to be pushed out and in most cases, then not taken up in the current Sprint. Such an event happening also reduces the confidence that the team has with the Product Owner. To avoid such cases, doing Product Backlog meetings in a previous Sprint provides some great advantages to the specific role of the Product Owner.
- The team is able to provide some rough estimates of the tasks, sometimes leading to situations where the Product Owner is able to do an approximation of the effort required for a feature vs. the benefits, and take a more appropriate decision. We had a case where the feature looked doable in a specific time frame, but it turned out that the research done by the team revealed that the technology required to do the feature as per the proposed workflows needed a technical solution that was not yet available cheaply (the licensing cost was high) and this helped the Product Owner take a more nuanced decision.
- When the Product Owner is defining the User Stories, he / she does not have too much in terms of reviews from others or contributions. However, when some of the responsibility for refining the more complex User Stories is shared by the team through the process of Product Backlog Grooming, a skilled Product Owner can ensure that the overall experience of the team and their comfort with the current feature can result in some great refinements to the User Stories.
- Showing the User Story to the team ensures that the team will have advance knowledge of User stories before the advent of the Sprint and gives them more time to point out gotchas as well as refinements before the next sprint starts. Some of this feedback comes back to the Product Owner and can provide some more inputs.
- With the presence of the Product Backlog grooming, the Product Owner is forced to put more effort into ensuring that the User stories are selected for the next Sprint well before the start of the next Sprint. This helps the Product Owner to develop techniques for taking into account the various factors deciding the prioritzation of the features and communicate the same to other people on a regular basis.
I have been writing a number of posts about the advantages of Backlog Product Grooming, including the advantages it presents for ensuring that the Sprint Planning meeting is far smoother. However, there is a flip side to the story, and there are a number of reasons why the Product Backlog meeting can actually be troublesome for teams, especially when the team is not convinced about the need for doing the meeting. Here are some reasons about why the meeting could end up being painful, and if teams are wanting to do the Backlog meeting, they need to ensure that they have solutions to these and other problems rather than rushing directly into this meeting (each of these points can have multiple ways of solving, and trying to provide resolution would make this post far too long):
- It’s yet another meeting. There are multiple meetings that the team needs to attend such as the Daily Scrum meeting (and any spin off meetings to resolve issues raised during the Daily Scrum), the Sprint opening and closing meetings, and so on. And when the Sprint duration is less than 3 weeks, it just seems to be perceived that these meetings take up too much time, which can make the team uncomfortable (they tend to associate a meeting as being different from actual work); now when you add periodic Product Backlog Grooming meetings, it can only cause issues.
- They perceive this task of getting into some detail to the User Stories as something that needs to be owned by the Product Owner and the designer and it can happen quite often that they believe that this is not something for the team before the Sprint Planning meeting.
- Different skill levels in the team, especially when it relates to Scrum. So when there is a discussion about designing and refining User Stories, experienced team members can do it much quicker than newer team members and in turn this can cause frustration about the slow pace of work in this area.
- In many areas, the Product Owner has a much better functional understanding of the product and the customer workflows (not the ones in the existing product), and the team cannot match the level of understanding of the Product Owner in this short time, and this can cause frustration since this whole process takes time.
- The team can feel that they are wasting time, that they are supposed to be doing the work allocated to them in the current Sprint rather than the Backlog Grooming meeting (this can be helped if the time set for the Backlog meeting is accounted for in a task in the Sprint).
- Even the tool can cause frustration. The Product Owner could be finding problems in using the tool and this would cause the pace of progress to be slow, which can also be frustrating for the team.
- Time limits for the meeting. Since a Backlog meeting can be important, many times I have seen teams extending these meetings to ensure that all the items that were needed have been discussed, but extended meetings can be the source of great frustration to many members of the team.
There can be numerous other reasons why the Product Backlog meeting can be problematic for teams; teams need to ensure that they understand the benefits and advantages of the meeting and only then start doing such a meeting.
When teams are using Scrum as their development model, there is a lot more responsibility added to the different constituents of the team; the 2 primary responsibility members of the team are the Product Owner and the other being the Scrum team (the Scrum Master really does not have so much explicit authority – it is derived from interactions with the team and trying to guide them to come to the right next step). In the case of the Product Owner, there is a lot of stuff that the Product Owner needs to do when using Scrum – Have primary responsibility for the Product Backlog and details of features (through fleshing out details in User Stories), working closely with the team to ensure that there is a clear understanding of the feature, Accept or reject the feature during the end-Sprint demo, and many other such areas.
When you think about all these, they do provide a good sense of authority and responsibility during the development of the project, but there are some problems. The big animal in all these theories about Scrum include senior management, and the need to ensure that they trust the Product Owner and the team (it is also realistic to think that when a product is important for an organization, senior managers will get involved at every stage, trying to determine whether the right features are there, whether the team’s productivity is high and trying to ensure that it gets higher, ongoing status of the project, and so on). Many of these queries are not just in a simple report, but actual questions and answers by the senior management.
The problem happens when such interference coincides with a situation where the Product Owner really does not have the authority that he or she needs. I have seen in a situation where the senior manager considered himself also an expert on how users reacted, and hence only those features which the manager thought were justifiable were approved out of the ones proposed by the Product Owner. Such a situation causes huge problems for the Product Owner, and overall for the product.
The assumption in all such cases is that there is a right for senior management to be able to approve or disapprove of the future feature set of the product, but at the same time, there needs to be a lot of attention paid that the Product Owner gets the authority that he or she needs. For working on the feature set for the product, there are a number of different stakeholders who have to be brought onto the same path (such as the team, experience designers, marketing, senior management), and if there is a perception that the Product Owner does not have the required amount of authority and independence to drive the list of features / User stories that he or she feels are best for the product, it makes the job of the Product Owner much more difficult. Even senior team members would be tempted to understand that since there are empowerment issues with the role of the Product Owner, they can make their own points clear in terms of features that they would like. This takes away from the role of the Product Owner in having direct responsibility for the Product Backlog in practical terms.
When speaking to the Product Management team about the transition to Scrum, they face huge challenges just adjusting to the new role. Many people from management have considered that the role of the Product Manager involves the least amount of transition; it is the team and the managers who have to make the maximum adjustment, but at the same time, for the Product Management team, it is not just a name change from Product Manager to Product Owner, but there are other changes that happen – even the process used by the Product Owner in terms of interaction with the team and communication changes. I used to see a Product Owner (formerly the Product Manager) struggling with trying to get the right level of detail in the User Stories that the team wanted for the Sprint Planning, and this was a source of great tension for many Sprints until things got somewhat better.
I am not going to be doing a comparison between the Product Manager and the Product Owner role in this post, instead will just work at pointing out some of the work that the Product Owner is expected to drive / lead as a part of the scrum process:
- The Product Owner is the one responsible for the Product Backlog, and since the Product Backlog is the primary artifact describing the impending list of features, this is a big responsibility. It means that part of the role of the Product Owner is to ensure that features are updated as the environment changes (competition comes out with something new or different; features no longer seem relevant); it also means that the Product Owner has the primary responsibility for figuring out new features as well as reviewing features suggested by others (and even if the Product Owner has help in this process, he/she still owns the process).
- Staying with the Product Backlog, for every Sprint, the Product Owner has to be sure that the features in the Backlog are in a state that they are ready for the Sprint Planning and the number of features so selected are enough to cover the entire duration of the Sprint (which means that the Product Owner should have a rough idea of the overall estimate for the features selected for the Sprint).
- Act as the single point of reference for queries that the team may have on features, and be able to react fast during the Sprint cycle if the team has queries that are not anticipated by the Product Owner earlier.
- Since the project cycle moves from Sprint to Sprint, it is also required that an overall road map be prepared by the Product Owner and features in individual Sprints form part of that roadmap.
- In the end of the Sprint demo, the Product Owner gives the yea or the no (has to decide whether the User Stories developed during the Sprint are as required, and maybe also take the same to the client).
- The Product Owner also has to take responsibility for the release planning and acts as the primary channel to external clients. Even internally, significant and senior stakeholders have been known to want status from the Product Owner about the status of the project rather than working with the team or the Scrum Master.