Agile Product Owner

The product owner, the person that wants your team to provide him with a working product.

In most corporations linking Agile to Business strikes directly to one's mind as an oxymoron. Business takes ages to make a decision, most of the time they do not know what they want, and more often than not, they just expect IT to deliver what they want in time and they forget about it until the release date is upon them.

So how do you convince them to get involved into an Agile process?


The team

First burden is to have make them understand they are indeed part of the team, because quite simple put, they will not get involved if they do not understand that the success or failure in delivery what they want, also depends upon their work and involvement in the process.

• They are also responsible for the success or failure of delivering.

User Stories

Scrum 101, PO must create the user stories. how I wish this was always true. It is a normal reaction, although not the correct one in my honest opinion, to have an analyst create the user stories based upon business requirements. This approach has several flaws.

The PO feels detached of the project and for him nothing has changed, he just created some vague requirements and up to the development team to figure them out. Then we're putting a middleman who interprets the requirements based upon his knowledge and experience on what business wants.

Forget that! It might be useful to have the analyst next to the PO when they are creating the stories. They will show themselves pretty helpful in finding pitfalls and explaining to business what the result of their choices might be, but they do not have to influence on what the PO actually wants!

Explain the PO the "as ... I want to ...." principle when creating stories. It is also a big problem when the PO things he has to create stories such as "call this back-end and get this information", stories must be simple, yet, they need to be complete, so no misinterpretations are possible, or at least, very few are possible.

"As a user I can login to the system" ... Everyone, even a non technical person can understand that, what it is all about and what needs to be done.

Then, a very common mistake, is to obviate the acceptance criteria. Why do you need them? Why do they need to be as complete as possible? For me, the acceptance criteria is the only valid, undeniable, and clear method to check that a user story can be accepted or not. If the AC's are ok, then the story should be ok. Yes, there might still be bugs that need to be corrected and so put on the board, but any change on these AC's after or during the demo, means that a new story has to be created, estimated and prioritized.

Forcing the PO to make good acceptance criteria has three main benefits:

1. The developers know what they need to do and nothing is left to their interpretation
2. Testers know what are their testing priorities (the AC's)
3. The PO has the certainty that what he wants is clear to everybody.

The Daily Scrum

Making them come to the daily stand up might seems like an obvious thing, but in most of the daily stand ups I handle or just observe, the PO is never there. and even if they think they have nothing to say, make them say something, even if it is "everything is ok for me". Why? because they will get the feeling that everybody actually is listening, but that he is also part of the team when listening to others. You know, I talk they listen, they talk, I listen, we all must be at the same level then, right?

Also, try to keep the daily scrum as little technical as possible, the PO is not necessarily a tech guy, so all this development chit chat might just bore him and make him to never come again.

The Demo

Another Scrum basic, but it is often skipped. No other person but the PO should be giving the demo. Giving the demo provides a new dimension concerning not only their responsibility towards the delivered product, but also towards their pride on being part of what it is being demoed.

A very nice side effect of the PO demoing the product, is that while explaining the product, they start to understand it better, and understanding what they are working on is essential for the success of the project, not only for him, but for the team.

A successful demo always fills the PO with this joy and pride, and reassure hims that the project is going on the right track.


Bottom-line, It will take some time to change his/her mind, but I can assure you, it is not an impossible task, and I can't explain the joy the team fels when you hear the PO say after the demo:

"Guys, congratulations, you have really made a good Job, there is no doubt that Scrum is the way to go for future projects"