Who Should Be The Product Owner?

Recently, I wrote an article on ScrumAlliance that says that Principle Software Engineer is not a good choice for the role of Product Owner.

In followup, I got an email from a Scrum enthusiast saying he understood the point but then who should be the Product Owner in a Scrum team?

It is a good question.

Unfortunately, it is often misunderstood by even senior management of Scrum-novice organizations.

The Product Owner is someone who builds, shares and establishes the product vision and inspires the team to self-organize and make that vision take form of the product, fast.

The Product owner operates from compass and not just following a map. And that’s why there is no specific set of “processes” that can make a good Product Owner. He is free to do all the activities that stay true to its definition.

Of course the activities that the Product Owner carries out may include collaborating, answering questions, providing answers and so on but at the end of the day, they are just that – activities. Scrum is not about the activities. Scrum is about the results!

To better understand this role, let me use life as metaphor.

Imagine that life is a Scrum Project and you’re the Product Owner of it. Your goal is to build, share and establish the vision for the difference you have dreamt to make and inspire the people on your team (your family members, relatives, friends, colleagues, community fellows and so on) to join the mission to accomplish your goal, fast.

What sort of process you should be following to be a good Product Owner in this case?

The processes that get you closer to your goal!

The same logic applies to the Product Owner role: The Product Owner should be someone who can build, share and establish the product vision and inspire the team to self-organize and make the vision take form of the product, fast!

How Much Documentation Should a Scrum Team Do?

I get this question invariably asked by almost every team that’s new to Scrum.

“Documentation that is just enough,” is the theoretical answer.

Almost always, the next question follows, “What’s just enough documentation?”

just enough documentation

Just enough documentation is what serves the sprint purpose. Imagine the following scenario:

  • Product: A Mobile iOS App in the Travel Niche
  • Pretext: Version 1.0 of the App is already in the market and people are using it. It has generated a user base of about 15000 and many people have requested  different features via App’s support a feature option.
  • Sprint Goal: Build and release version 1.1 of the already successful App. Version 1.1 should have 3 most demanded features by the end users. Out of 3 features, one feature required R&D and hence Scrum is a better choice.
  • Sprint Duration: 2 weeks
  • Team Size: 5
  • Team Details: ScrumMaster (1), Product Owner (1) and Team members (3). Out of 3 team members, one is Graphic Designer, one is Software Developer and the 3rd one is App Support Executive.

Effective documentation in this case could be as follows:

  1. User Stories for the 3 features
  2. Photoshop PSD file with explanatory layer name and optionally a readme.txt file with bullets of specific instructions if any
  3. Readable, modular, commented code that itself is self-explanatory with occasional in-code comments stating why a complex thing is done the way it is done
  4. Updates in the App Support FAQs / Other Support Docs that are affected by introduction of these features

A Scrum team’s goal is to deliver value, fast. Above might act as just enough documentation for the needs. The good thing about Scrum is a specific ceremony called Sprint Retrospective which becomes instrumental in inspecting and adapting to what turns out as the right thing.

When we talk about documentation, often a question comes about the User Manual.

Let’s consider the same in the above scenario: Given it’s an iOS App, it won’t be a good idea to develop a User Manual for the same – The App’s UX should be so natural to the user that they don’t need to refer to the manual.

It is easy to agree to develop a user manual for an iOS app but in fact, that will be a disservice to the end users and the client itself – as you’re disregarding the manual-less experience that is possible to provide to the end user.

Or even better, provide the functionality built in app that enables the user to learn the App by seeing it in action. The need to documentation turned into a functionality!

Many people will say that if client demands, carry out the documentation. However, I do not buy into the idea that if your client requires XYZ documents to be created, you should carry them out without asking questions that provoke her to think – you should explain your client the value a particular activity will bring or the value that it will negatively impact. Sure, typically it is done by the Product Owner but as team members, if you decide to do something in which you don’t believe, you cannot deliver value.

Spirit of Scrum is not to negotiate but to collaborate – when you collaborate towards ONE goal, no one is superior to the other.

Sure in typical Business situations, you might have to do what might look like “anti-scrum” or not “scrum-friendly” – if you choose to do so, do it with awareness.