Product - Agile and Scrum Blog

Typical Mistake of Product Owners

One of the typical mistakes of Product Owners is, that they still live in the world of requirements. They still believe, they know what needs to be done. Or at least, that their customers know what needs to be done. So, they spend all the effort on gathering requirements, asking “what do you want us to deliver?” and through that they end up with this crappy Backlog, that grows to unlimited sizes. But none of that is true. The world had changed. It’s more unpredictable, is unstable, and complex by nature. I believe it’s a time to be honest and admit that we don’t know what needs to be done. All we know, is what do we want to achieve. But we don’t know how. And that’s a problem in traditional world. Because how can we plan what to do if we don’t know that. So that whole shift brought a lot of frustration to the industry past decade. And organizations were approaching it in the wrong way. They try to estimate better. They try to detail requirements. None of that worked.

So, what’s the solution to this problem? I think the solution is surprisingly simple, but we need to fundamentally change how we organize our business and how we prioritize. We need to look at things in more strategic way. We need to embrace the business agility and start welcoming changes already at the very beginning. The backlog was never meant to be fixed to-do list. Quite the opposite. It was meant to be dynamic and changeable. It was not meant to be full of requirements describing all the possibility details which must be delivered. Instead, the backlog supposed to be a collection of business cases, of small little hypothesis we phrased together to describe the needs of our customers, the pains of the business. And that’s very different from what you usually see in organizations.

So how can a backlog item look like?

Requirement

A detailed description of a functionality to be delivered. Very traditional, works for stable, known environments with no surprises. Usually large but can be split into smaller pieces.

The system shall provide users with an AI-based assistant that analyzes their transaction history and generates personalized financial tips. The assistant must support natural language queries and return responses in under 2 seconds.

The system shall allow users to set monthly spending limits for expense categories (e.g., dining, groceries, entertainment) and shall notify users via in-app alert when 80% of the limit is reached.

User story

If written correctly, it’s a frame for conversation with our users to describe a business case. It’s customer centric, value driven. It’s a good start to address customer’s needs. As a [persona] I want [what] So that [need].

As a Jenny (single mother, budget-conscious),

I want to have control over my monthly spending

so that I can keep my finances safe.

Story map

Like user story, but covering larger functionality, bringing the whole context of the user’s need. Is more consistent and coherent, balancing the customer perspective and the value.

Story: Jenny needs to Improve financial health

Map: Steps/Options/Journey:

Connect Accounts	Visualize Expenses	Recommend	Track Progress
Bank API	Automatic Categories	Tailored Tips	Progress Bar
CSV	Charts	Rules-based Suggestions	Gamification
QR Code	Manual Tags	Benchmark Suggestion	Predictive Trends
	Compare History	Savings Plans	Email Reports
	Weekly Trends

Impact map

A mind map describing hypothesis in visual form. It’s created around well-defined business product goals to maximize the value towards the goal. It helps you to be very strategic. Business Goal (SMART) → Actor (Who can influence the outcome?) → Impact (How shall the actors behavior change?) → Scope (What can we do to support that change?).

Goal: Help people make better financial decisions: (15% increase in savings or a 20% reduction in non-essential spending)

Actor: Young professionals

Impact: Limit ad-hoc spending

Scope: AI assistant that offers spending alerts and budget tips

Hypothesis

Optimizes for testing assumptions and learning from them. It’s highly adaptive, emphasizing adaptability, and regular feedback. We believe [Functionality] Will result [Outcome] We will have confidence to proceed [Measures].

We believe that providing users with personalized, AI-driven financial insights based on their real-time spending behavior

Will result in a 15% increase in savings or a 20% reduction in non-essential expenses

We will have confidence to proceed if at least 60% of engaged users show measurable improvement in their financial behavior and report feeling more in control of their finances through in-app surveys or usage metrics.

And there is more. However, the more venerable, unpredictable, complex and ambiguous your environment is, the more you need to leverage the flexible and business-oriented techniques further down on my list. Requirements are not successful in unpredictable world. Organizations need more business agility, so forget requirements and try some story mapping, impact mapping, or hypothesis. Business agility is not an option anymore. It’s a necessity.

The Power of Metaphors

One of the tools I have started using more over the years is a metaphor. Many years ago I was taught the Speed Boat retrospective and tried it with teams. It brought great energy and fun, it helped us to uncover different perspectives. But it never occurred to me that I should take the idea to the next level and use it in other situations. So let’s have a look at different situations where metaphor can be useful.

Organizations are often used to look at outputs, measure effort, and compare velocity. One of the shifts that need to happen is from functionality to business value or in other words from output to outcome. And it’s not an easy shift, especially when the organization is still project-oriented, running on the “fixed scope” mindset. One of the reasons I’m using the metaphor with Product Owners is to shake with their business as usual – we deliver requirements – and reset their thinking about the product. I’m leveraging the Three levels of Reality concept I learned from ORSC and guiding them through the Sentient Essence level by exploring a metaphor, through the Dreaming level where the most collaboration at Backlog refinement is happening, to the Consensus Reality level they are used to by setting goals and objectives. The Sentient Essence level is about feelings it’s the spirit of things. It’s where the purpose is born. And the purpose is often forgotten in traditional organizations.

Using a metaphor is also a great icebreaker and team building. You see how different people collaborate, how they react to different perspectives, and look for commonalities. It can help teams to create an identity and become a better team together.

It’s also a great tool for ScrumMasters to reflect on where they like to have the team or the entire organization in six months, a year, or three years.

I’m often starting by letting individuals draw some animal, real or imaginary. Depending on the situation I might help them explore that metaphor more to uncover different aspects of it. Drawing is just one way how to visualize the metaphor. You can ask people to describe it, to create a gesture, song, or dance. There are no limits.

For example “We are like a flock of birds, they can fly fast, but not for long. Some got tired quickly and started falling down but the others continued without noticing. They are strong, they have great eyes, but once they start the journey they don’t like to change the direction.”

Then we compare the individual drawings, looking for similarities and uncovering the differences. And start integrating different perspectives into a coherent picture. It’s different than talking about numbers, goals, and objectives. It brings energy and creativity and I would encourage you to try it. Let me know how it worked for you.

Great Product Owners

Great Product Owners are not only having business knowledge, authority and time, but also a few additional skills which people often don’t expect.

“Great Product Owner is a facilitator, coach, negotiator.”

You will usually hear about coaching and facilitation in the connection with the ScrumMaster role. So why do we talk about Product Owners and facilitation and coaching? Can’t they just use the service of the ScrumMaster? They can. However, in many environments Product Owners are not the ‘heroes’ who decide on everything. Quite the opposite. They are great listeners, who have respect for different customer voices, and their highest value to the system is they can find alignment through coaching and facilitation. Customers (users, stakeholders, shareholders, sponsors, …) never agree with each other, they all have their own preferences and needs. Great Product Owners can help customers to reconnect with their needs instead of pushing what they want. In order to be able to do so, they need to step back, acknowledge that their requests are representing just one way of achieving their goals, and search for other options that would satisfy the needs of more groups than before. In other words, they need to be good at integrative negotiation and finding win-win solutions.

Finally, the last skill great Product Owner needs is visual facilitation. It seems like an unimportant skill, but the good picture speaks for more than a thousand words and can create real magic in searching for alignment. Visualization creates transparency, and transparency is ground for accountability. You would be surprised how good visualization of a conversation and different perspectives can help people to change their mind and proactively help you in searching for alignment.

Maybe those skills are not on the top of the Product Owners list at the beginning, however, the same skills differentiate great Product Owner from the newbies.

Five books every Product Owner should read

To continue my with my book recommendations (check the five books every ScrumMaster should read, and five books Agile Leader shall read), I have several books here, I would recommend every Product Owner to read. It’s a mix which will help you to understand Agile Product Ownership, Discovery and delivery process in much broader perspective. Enjoy reading 🙂

Impact Mapping: Making a big impact with software products and projects is a practical guide to impact mapping, a simple yet incredibly effective method for collaborative strategic planning that helps organizations make an impact with software. Impact mapping helps to create better plans and roadmaps that ensure alignment of business and delivery, and are easily adaptable to change. Impact mapping fits nicely into several current trends in software product management and release planning, including goal-oriented requirements engineering, frequent iterative delivery, agile and lean software methods, lean startup product development cycles, and design thinking.
Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In the book, Agile Alliance co-founder Mike Cohn discusses the philosophy of the agile estimate and planning, and shows you exactly how to get the job done with real-world examples and case studies. This book is a must-have agile estimation tool for your development toolbox.
User Story Mapping: Discover the Whole Story, Build the Right Product shows you how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features.
Innovation Games®: Creating Breakthrough Products Through Collaborative Play is a must-read for anyone involved in market research and product or service development (which, when you think about it, means virtually everyone). Innovation is incredibly simple. All you have to do is accurately predict what your customers want, need, and will pay for. Oh, wait. Sorry. That’s actually very hard. At least with traditional tools. So how do you find this information? Well, you can just ask your customers what they want. The problem, of course, is that with most truly breakthrough innovations, current and potential customers don’t actually know what they want before they see it. If you just try to deliver what they already want, you’ll never truly innovate. Even worse, traditional market research practices prove that often, customers have trouble articulating what, exactly, they want in the first place.
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses is about a new approach being adopted across the globe, changing the way companies are built and new products are launched. The Lean Startup approach fosters companies that are both more capital efficient and that leverage human creativity more effectively. Inspired by lessons from lean manufacturing, it relies on “validated learning,” rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute. Rather than wasting time creating elaborate business plans, The Lean Startup offers entrepreneurs – in companies of all sizes – a way to test their vision continuously, to adapt and adjust before it’s too late.

Make product as wide as possible

Some time ago, when I first heard the definition of LeSS (Large-Scale Scrum) product, I found it a bit unrealistic. Large-Scale Scrum is one of the Agile Scaling methods and I happen to like it as it’s very close to what I had experienced to be successful in various environments before. But the definition of the product is quite wide. Specifically – the product shall be as wide as possible, but still practical. If the customer feels it’s the same product or if it’s similar from technical perspective, it is the same product. When you start to apply this rule, in general it means that most of the companies have one product only.

Let me give you a few examples… Amazon and all its services shall be one product because that is how customers see it, the service company delivering internet solutions and mobile apps for variety of the customers is one product despite of the diversity of the customers and technology, the maintenance and the new development is one product as it is same from the technical perspective. Your projects are just Epics in your Product Backlog. When you think about it for a while it makes sense, as you need consistency in your delivered functionalities, flexibility to be business driven and ability to prioritize your business only by business value not by technical skills or domains. This is the real crossfunctionality we aim for. It’s not that difficult despite of the complexity of your product. The people who create our software are usually having university degree which shows they can learn. They are smart and creative software engineers. They can make it. If you do it this way it makes everything so much easier as dependencies at code level are much simpler than dependencies at business level.

Definition of Done

Definition of Done (DoD) is a simple thing, although people are often struggling with it. It only defines what “done” means. It brings consistency into the product delivery. It sets the bar of quality we all keep the same. People often mix it with the acceptance criteria and are confused. So let me summarize it. Definition of Done shall be the same for all Product Backlog Items, as we need consistency, we need to know which quality standards are kept. Definition of Done is created as an agreement between Product Owner and Development Team, so it contains both technical and business quality requirements. It shall be stable for the product and not change Sprint to Sprint. Eventually, we can improve it, but we aim for consistency so we keep it stable. Definition of Done is the same for all teams who work on the Product Backlog to keep that consistency.

So how can such Definition of done look?

Coded
Tested
Reviewed
Documented
Running on test server
Accepted by Product Owner

You can make it more specific:

Coded according to Product Backlog Item (User Story) definition
Automated tests (unit, functional)
Reviewed (by different team member)
Documented (internal)
Running on test server
Accepted by Product Owner

Eventually, in some time we may improve it for example as follows:

Coded
Tested
Reviewed
Documented
User documentation
Translated to Chinese, French and German
Running on production
Contains business measures how users used it
Accepted by Product Owner

In this case, we achieved continuous delivery within our Sprint. We release each Backlog item to our users directly whenever it’s done. We need to translate it as a part of that otherwise we can’t be able to release. And we have to add some business measures to know if we are getting the expected impact or not and get fast feedback. As you might see, the more the organization is Agile and teams cross-functional, the wider is their Definition of Done.

Definition of Done shall be visible so everybody can see it. Never compromise. The User Story is either done or not. Any other state only brings chaos and makes any release completely unpredictable.

User Story as a Card

User Story is one of the most common formats how to write Product Backlog Item. It has specific format which forces people to focus on business value.

As a [user | role| persona]
I want to get [functionality]
So that I get [business value]

As an example of such User Story for my online beer store called “Berrer” we can write the following:

As Jon (busy manager with no time)
I want to get beers selected by “Beerer”
So that I can impress my friends by variety of rare brands.

It shall give us three different information – Who, What, and Why – which must fit together and once you read it to someone it shall create consistent story together. As you may have noticed the User Story looks at the functionality from the business perspective and is customer centric (note that customers are all user, stakeholders, other teams, … ). We never define how exactly it shall be solved, but describe the business impact we want to achieve.

Write Acceptance criteria was never good idea

Having that definition, companies are often missing the place where to write the exact specification. But there is none. It’s all about conversation. It should fit a small index card. Having said that, teams are still fighting and try to keep it as close as possible to the traditional detailed specification. One way how keep it close is to add detail as Acceptance criteria. It usually looks as checklist of all possible details you shall/shall not implement. It seems to be useful for teams who have limited understanding of business and product but it’s not. To give you an example of such Acceptance Criteria for the above defined User Story, it can look like this:

Beers from all continents
At least one beer from Belgium
Several small local breweries
One light, dark, Ale, Pils

As a result of it development team is not involved in the story definition anymore. They just take those points one by one and implement it. If it’s not working as we missed something, it’s not their fault but the Product Owners’. He shall have made the missing piece part of the Acceptance criteria. So let’s have a look to better solution.

Define Conditions of Satisfaction instead

As we said before, User Story is about conversation. It shall be simple, clear, and easy to remember. If you write well so it is small enough, there is no need for any additional information at the back side of the card. However sometimes you might find it useful to stress certain expected behavior / impact. In such case we turn the User Story card and write the Conditions of satisfaction. For the above defined story it might be:

Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.

As a result of this the team is focusing on solving user problem instead of implementing what was defined before. The implementation usually starts with conversation. How can we deliver the more value with less effort? What is the minimal functionality we have to deliver? How can we address his needs? We need everyone involved, everyone interested, and everyone understand the overall business, personas, their needs and their dreams.

It may take bit longer at the beginning, but it’s worth investing the effort as the committed team which is living by the product can always come up with better solution then one Product Owner.

Writing Acceptance criteria is our legacy from traditional world, while defining Conditions of satisfaction is very Agile. Agile and Scrum is mindset. If you have it, it doesn’t matter how you write your User Stories because you already understand the fundamental difference. It’s about value to be delivered to the customer, instead effort, items delivery, and velocity. If you don’t, changing only the label won’t help. You would have to significantly change the way you think about Backlog items and that might be very painful and long process where User Story format with Conditions of satisfaction will help. I went through that change with several companies during Agile Coaching and it was always worth of the effort. If you want to get bit more practice, I also teach it at CSPO – Certified Scrum Product Owner class.

Product Backlog Example

When I teach Agile and Scrum classes, people often ask for Product Backlog Example. In order to start, you don’t need any complex tool. You can start with paper index cards and if you like simple Microsoft Excel or Google Sheet.

The minimum Product Backlog you need can be as simple as the card for each functionality (one column in the Excel):

Automatic beer selection for the party
Choose new beer to taste
Order favorite beers again
Recommend expensive beers

As I wrote in the previous blog about User Stories, the most common way how to define Backlog item is User Story. In that case you might want to add name for fast reference (however when you are using index cards you usually don’t do that and visualize by underline or color some important part), and if needed add conditions of satisfaction to the back side of the card.

Name
UserStory
Conditions of Satisfaction

Automatic selection
As Jon (busy manager with no time), I want to get beers selected by “Beerer”, so that I can impress my friends by variety of rare brands.
Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.

New beers to taste
As Jon I want to see beer catalog so I can choose the some new one to taste.
Jon can see different tastes directly from the catalog page and don’t have to go into beer details.

Favorite beer order
As returning customer I want to see my favorite beers, so I can order them again.
(keep empty – conditions of satisfaction are optional).

Recommend expensive beers
As Store Owner I want “Berrer” recommend expensive beers so we increase our profit.
Customers are not feeling under the pressure to spend too much.

If you like you may also add a few optional fields like ID, Estimate, Epic, and Priority(which can be used to sort your Backlog in Business priority order). They all fit the index card space, but if you like to use any tool, it may look like this:

ID	PBI	Estimate	Epic	Priority
234	Automatic beer selection for the party	20	Order	1
556	Choose new beer to taste	8	Order	15
123	Order favorite beers again	3	Order	40
89	Recommend expensive beers	5	Profit	50

That’s it. As you see you don’t need any complex tools to handle your Product Backlog. Paper index card or Excel sheet is more than enough to take care of “deep enough” Product Backlog and to define clear Product Backlog Items. So don’t make it more difficult than it is.