Product - Agile and Scrum Blog

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.