Agile Faux-Pas: Lack of a Product Owner

Agile Software development has taken the world by storm and its adoption is at unprecedented levels these days. Almost everyone these days talks about Agile software development and agility as a discipline. So you would expect that everyone learns and practices Agile Software development the right way at the right pace. Sadly that is not the case. There are countless examples where Agile Software development is not practised correctly.

That is the point of this new series of blogs, the Agile Faux-Pas series. While none of these will kill your software development (or may do in extreme cases), they definitely make you less Agile and often defeat the purpose of going Agile.

One very common ‘faux-pas’ is the lack of a proper Product Owner.

It usually manifests itself in the following ways.

  • Many teams and companies assume they don’t need a Product Owner(PO) or they have someone take over this role part time.
  • Others go the waterfall way and use a requirements document as a product owner.
  • Still some others improvise and have neither a requirements document or a PO. They just get the senior most team member or someone from management to act as a PO when needed.

This is a clear departure from Agile Principles. One of the main reasons for this is a wrong understanding of the PO’s purpose. Or even a total lack of understanding. Let me elaborate on that a bit and also throw light on how the PO is essential to the success of Scrum. For that let us first see what are his roles and responsibilities (in no particular order) and why they are important.

  • Demos and Constant Feedback: For the dev team’s point of view, the PO is the customer. In every Sprint review, the team gives the PO a demo of an incremental version of the product that has more value (features, bug fixes, enhancements) than the last one. This demo gives the PO an opportunity to look at the product and answer queries about whether the stories taken up for that sprint were done right. The PO should already have talked to the real customer or their representatives to get detailed product specs and the priority of each spec. Armed with that info, the PO should be able to answer any product specification related question the developer might ask. Also, the PO should be available to answer requirements related queries at any time during the sprint. Overall this provides much better feedback than a document, even a constantly updated one. The point to note is that while the PO maintains requirements in the Sprint and Product backlogs, they are not alternatives for him being personally available to look at the product, give feedback and clarify queries. It is this face to face communication that allows the dev team to constantly build the right features in the right order. Without that, there would be a great deal of wasted effort and rework.
  • Backlogs and their grooming:
    • Product and Sprint Backlogs are the most important artefacts maintained by the PO for each product under development. The Product backlog contains stories that need to be go into the product while the Sprint backlog has stories that need to be completed in a particular Sprint. In both backlogs, items are arranged according to Priority and this Priority is sacrosanct. At all times only the highest priority items should be taken for processing. These backlogs and their priorities are the PO’s responsibility and they are arrived at by constantly talking to the customer or their representatives.
    • Also before a sprint begins, the PO along with the scrum master works on making user stories for that Sprint “Sprint Ready” which essentially means the following.
      • Latest requirements: Requirements can and will change while the product is being built. The PO makes sure that before each sprint begins, each backlog item contains the latest specs.
      • Clear and well defined stories: The PO makes sure that there is no lack of clarity about what each story means. This can be achieved by mentioning the specs clearly with the stories in the backlog and also by being personally available to resolve queries face to face.
      • Acceptance criteria: The PO defines what constitutes successful delivery of each story before the sprint begins, allowing the team to demonstrate success (or not) for each feature developed.
  • Business inputs for the product: For any product, business inputs are key development drivers. As I mentioned earlier, the PO is a virtual customer for the dev team (including QA). The PO has all data about how the product is supposed to run in the field and is the single point of contact for the dev team to be able to get these insights. And since the PO has all the data, he usually is the best judge of the correct expected behaviour of the product in the field. The availability or lack of these insights could make or break a product.

As you have seen, the PO overall brings clarity to the developers, a clarity that probably cannot be matched by other substitutes. It is this very clarity and constant availability for face to face clarifications that make the PO’s an indispensable role for a truly Agile team.

There however are many reasons why teams are not able to have a proper Product Owner, I will look into some of those reasons in another blog and hopefully be able to provide solutions for that. I will also be looking into some best practices and anti patterns with respect to a PO in that blog.

Also, please share your feedback in the comments. I would love to hear your opinions and questions. Do subscribe if you feel that this blog is useful for you.

References

  • Implications of your PO being missing in action here.
  • What happens when you don’t have a PO at all. Read a thoughtful perspective here.
  • And here, why you need a dedicated product owner.