ScrumZen - Leverage Scrum, Deliver Results

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!

{ 1 comment }

How Much Documentation Should a Scrum Team Do?

April 27, 2014

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 is what serves the sprint purpose. Imagine the following scenario: Product: A Mobile iOS App in the Travel Niche Pretext: […]

0 comments Read more →

Is This Your Best Code?

January 25, 2014

This is the wrong question. The right question is, “What knowledge, skill, tool, framework or support will enable you to write better code than what you’ve written?” So what do you mean by better code and why should you care? Better Code does not always mean well structured, well documented, reusable code. Many a time, […]

0 comments Read more →

Scrum Teams and The “F” Word

December 8, 2013

What’s the “F” word in Scrum? Not [F]un. Not [F]ire. Not [F]ailure. What is it? Most scrum teams deal with software engineers so they are concerned more about engineering challenges than anything else in all what they do. In Daily Scrums. In Review Meetings. In Retrospectives. Often, they don’t pay active attention to important “F” […]

2 comments Read more →

3 Tips for Product Owners to Survive the Chicken Test

December 5, 2013

As a Product Owner, why should you even think about the Chicken Test? For a simple reason: You are accountable for ensuring that the product you’re working on achieves its goals. The chicken and pig metaphor suggests that the difference between ham and eggs is this: the hen is involved, but the pig is committed. […]

0 comments Read more →

The Problem With Preparing User Stories In Advance

September 17, 2013

is that it lacks the “ownership” part. Some Product Owners invest a lot of time creating user stories and provide them to the team in the sprint planning meeting. It is an opportunity lost to explore team’s point of views and knowledge. Stories created through such activities often serve as meaningless piece of document in […]

1 comment Read more →

How Every ScrumMaster Should Deal With Attention Issues?

August 6, 2013

Ever been part of a team where team members didn’t pay attention to what was being communicated? Yes, in Scrum teams also that happens. Especially in the Daily Stand-ups. Team members don’t always pay attention to what other team member is saying. Most people get this habit from their daily lives. They go to doctor […]

1 comment Read more →