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.