This week in my Agile class, the instructor pointed out a video article on the topic of Agile product ownership. The video article called Agile Product Ownership in a Nutshell was a fifteen minute short video that basically explained the Agile software development process in a nutshell. Although the video was about the whole Agile process, it went into great details talking about the importance and challenges of the Product Backlog. The Product Backlog is basically a list of everything that needs to be done for the product. It also tells the development team on what to build and when to build it.
According to the article, the Product Backlog is maintained by the Product Owner with inputs from both the stakeholders and the development team throughout the duration of the project. The Product Backlog can contain anything and everything that is needed to be done for the product. It can come from many different sources at different times. Because of this, it is important to maintain a list of what needs to be built. Whatever is not on this list, should not even be considered as a feature of the product. Therefore, if it needs to be built, it should be added the list first. People can talk all they want, but until it is written down and added to the list, it is just someone’s idea. In addition, it is important to have one list to keep track of everything. This ensures that everyone is looking at the same list and on the same page when it comes to prioritizing the backlogs. This list will be the single source and version of the truth.
Since there always seems to be more items in the Product Backlog than what the development team can do, one of the most important challenge for the Product Owner is to know when to say “no” to the stakeholders according to the article. The Product Backlog over time can accumulate to become a very large list of items. However, the development team can only go through a certain number of items at a time. The development team will become blogged down and ineffective if they try to take on more than what they can handle in a sprint. Therefore, the Product Owner must know when to say no to items that take up development time and not add a lot of value to the product. Stakeholders will always think that their backlog is the most important. If the Product Owner says yes to every feature request by the stakeholder, the Product Backlog can grow to become unmanageable. The Product Owner must act as the gate keeper to ensure that only the most important item gets into the sprint release. In additional, the Product Owner must also trim the current Product Backlog from time to time as requirement changes over time. This will ensure the Product Backlog is up-to-date with current needs and vision of the company.
Not all backlog items are the same. Some items takes more time to development, while other can be quick. Some items can add a lot more value, and some not as much. According to the article, the Product Owner must consider the four types of risk: business, social, tech, and cost/schedule to determine the priority of each backlog. The backlog items should align with the vision of the business. The development team must be able to build it and the task are technically feasible. In addition, it should be cost effective and able to be built on time. The Product Owner must weight in all these risk factors in coming up with the priority for the Product Backlog.
The article goes on to say that at first, the selected backlog items might be based on adding knowledge value for the team. At first, the backlogs might not add a lot of value for the customer, but necessary in order to build up the technical foundation for the team. The article brought up 3 overlapping circles of priority. The first is to “build the right thing” emphasized by the Product Owner. The second circle is to “build the things right” emphasized by the development team. The third circle is to “build it fast” emphasized by the scrum master. All are legit reasons for working on the selected backlog. Ideally priority should be set to satisfy all these conditions, but sometimes, you have to make tradeoffs. Making these tradeoffs are challenges of the Product Backlog faced by the Product Owner, stakeholders, and the development team.
Comments