A Product Owner’s best friend is Agile Principle #10:
Simplicity — the art of maximizing the amount of work not done — is essential.
If you are a product owner or a member of a team you have probably gotten this feeling each week when you are called into the Refinement session:
Oh no. Not Again.
If you’ve never had that feeling, then maybe this article is not for you.
Here are some general expert tips for product owners and teams that are based on my life as a product owner and a coach for teams internationally.
The backlog is not an infinite list of things to do with no relation between items.
Think of the last time you had to deal with a list that had a million items. Humans in general love lists but hate long ones. We often can’t remember beyond the first few items.
It is also true that humans don’t do well with one-dimensional monochromatic information.
There is a common saying in Scrum teams: “Put it in the backlog”. As a customer or product owner, when I hear this I think, “There it goes, this stuff will never get done”.
Try using a Problem Board that has notes for each category of work, but not all of the work in one list.
- Define a business problem you are trying to solve or a goal that you are trying to reach.
- Define a metric that describes how you can measure the fact that you are actually solving the problem.
- Define the features that can help you solve the problem.
You may have 20 to 30 goals or problems that you are solving in a quarter, irrespective of the scale of the product.
Getting items to a manageable lists
There is a myth in the Agile community that adding to the backlog is the easiest thing to do.
If there are 100 things in your backlog, and if you team does 5 items in a 2-week sprint, they need 20 sprints to finish the list.
If I am a stakeholder and I see my issue being added as the 101st item, I know I will not see it addressed for at least another six months to a year.
The concept presented is not new and has been validated by folks like Jeff Patton of Agile Product Design. Think of a product backlog as a uber list of three lists.
Opportunities: Any raw idea goes here. This is just acknowledging you heard someone. But you need to spend some time making sure what you added makes sense. Many times people are describing a problem they are facing or maybe saying something they think they need. Remember, you don’t know if this is a useful idea until you actually build it.
But building something is a huge cost. Remember the 80-20 rule: for every 100 items hitting the opportunities list, you push 20 to the filtered backlog. The 80 others hit the “Trashcan Backlog”.
A good product owner should validate each feature to see if the feature being built meets the goal. Let’s say you thought this feature is good, all the initial research you did shows that this is good, so you built it. You are surprised to see that even after a month or two of being in production, no customers are using it. Invoke Agile Principle #10: Do not shy away from requesting the team to take away the feature, the code, the test, etc.
Good product managers don’t always get things right. They experiment with ideas and try to validate them, but take them out if they don’t make sense based on measurable metrics.
Estimating Stories is a non-value-add activity.
Many teams struggle to get estimation right. Remember estimation is never correct, hence the word “estimate”. Agile teams use estimates to do a few things: to tell the PO they can do the stories in a sprint, to show confidence among team members that they can actually do it, and to gain a better understanding of the feature they are trying to build.
Non-value-add activity is anything that the customer cannot see. In most cases, the end customer cannot see your estimates or doesn’t care about them. Instead make sure every item you put in the team backlog is ready and possible to do in a sprint. It does not matter if it takes one day or 10 days. What matters is whether it goes into production at the end of the 10th day and creates output. Solving a customer’s problem is outcome. What we want is outcome not output.
Don’t fall into the business value trap
Product owners often struggle with how they are going to assign business value to a story. Many coaches and Agile gurus subscribe to this rule. Guess what — there are hardly any product owners who can do this well in a simple manner. There is a lot of theory around this, but really all we should care about is at the problem/goal board level — we should be able to identify a metric that tells us we are reaching a goal.
So don’t beat yourself up if you cannot find a way to assign business value to a user story.
Don’t fall into the “As a User, I want to Do Something” trap
“As a user, I want to do something so that <value>” was only meant to be a template. Little did we know that the world would turn around and spit out thousands of items on a backlog. It is really tough to read this machine language. Humans read backlogs not computers.
Instead, consider as a product owner doing a short 2-minute video of you describing the story to your team in a flip chart. One of my favorite product owners living in Germany does this all the time because her team members are in four countries.
Remember to value People over Process
Do what makes sense to you and the team. There is no right or wrong here. The only thing that matters is whether you can offer something of value to a customer that solves a problem they have.
Lastly, have fun with the team as you build the product. The backlog is just a medium to capture your thoughts. Without your voice behind it, it makes no sense. Talk to your team more often and see the difference.
