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.

Sprint Planning in 30 minutes

How much time takes your team to finish Sprint Planning? To my experience it could be anything in between of above mentioned 30 minutes and full day. If you are closer to the second option and it feels scary, annoying, waste of time for you, let’s have a look at few recommendations how to cut it out into 30 minutes.

First, let’s see how to run the Sprint Planning itself. I recommend Product Owners to come to the Sprint Planning with physical cards for each User Story. They quickly introduce them, answer questions if needed and then let the team choose out of them. Don’t bring the exact ordered list; let them freely choose from the cards. There are two reasons for that. First, you maximize work done as they can organize themselves in a way they are most efficient, and at the same time there is higher commitment as well. Second, you build a trust between team and Product Owner. You trust them they will choose the right User Story which brings the highest value at the moment. Once the team select the User Stories witch they believe they are able to finish within the next Sprint and put them on Scrum board, Product Owner and Scrum Master can leave and let the team finish the Sprint Planning. During this second phase team will collaboratively split the selected User Stories into maximum one day tasks and revise the Sprint Backlog commitment. After 30 min they are done, have full board of cards and can start working.

If that still feel unbelievable, let’s have a look to the preparation. There are three key recommendations you should do in order to make your planning fast and meaningful. First is for Product Owner. 2-3 days before the Sprint planning let the team know what are your priorities for the next Sprint, so they can have a look and prepare themselves, ask questions, etc. Second is proper Backlog Grooming. The goal of Backlog Grooming is make sure the team understand Product/Release backlog (i.e. all User Stories, Super User Stories, Epics and vision). At this time team do the estimations and help Product Owner to split User Stories which are too big, or add Acceptance Criteria. Once understood, they are ready to be planned to the Sprint.

To summarize it, if you are not able to do such fast planning, improve your preparation (team time to prepare, grooming, pre-planning) so the planning is here not to investigate new functionality but to confirm how much we can make. Doing that, you gain motivated team who is not wasting time at never ending planning, better reliable Sprint plans and higher backlog quality as you are not pushed to do splits and changes at the last moment. Start step by step and continuously decrease your time needed. It’ll go much faster than you would imagine.

Product Owner Development Model

What is the difference between requirements, use-cases and User Stories? I’ve been struggling with that question a lot. On one hand it is easy. It’s something completely different. On the other hand, that’s not anything which would help people to understand the difference on their way to implement Agile.
After some time working as Agile Coach, I created this Product Owner development model. It’s focused on product creation and Backlog item definition process.

Level one: User Story is just a special format of a sentence

At this basic level of understanding we are very close to the requirement-like specification. We keep the backlog in the Word document, as we anyway wrote very long sentences and extensive document chapters about the functionality. There is often huge mix of current functionality we want to keep, and new functions. The only change we do with that requirement document is to change/add User Story sentence instead of general name. So we get something like “As a MyCompany, I want new tariff, so that my customers are happier” followed by 2 pages long text description what the “tariff” exactly means. Such User Story may survive at team board for several Sprints without getting done. Surprising, isn’t it? We wrote User Story and it didn’t help!

So this stage is about documents. We create PowerPoint presentations to describe product goals and vision, we use complex roadmaps to define timeframe and we have written long specification documents to describe functionality. The more we write, the better product we have. The understanding of the role of Product Owner is very limited, decisions are often taken as a board of people without real product success responsibility.

Level two: We have ‘bigger fish to fry’, than write User Stories

At this stage we already understand that we have to describe our User Stories better. The team needs higher granularity and detail. But we don’t have time to write User Stories, so that we delegate that unimportant work to some administrative position called business analyst, business requirement specialist, business delivery manager, development team or whoever else is around. We don’t have a time to write such ‘technical’ details. It’s not important for us. Just make sure you will deliver it on time. We have bigger fish to fry. We have to talk to the customer. It’s more than enough to discuss our product ideas and high-level visions. We are responsible for Backlog, and yes, we prioritize it. However, the level of Epics is just about the right level of details.
So this stage is about big high-level decisions and quantity. We already have a Product Owner position, although that person is not often seen. Instead we have the army of people, who are willing to help official Product Owner with creating as many User Stories as you can imagine. What if we need that functionality in the future? Let’s describe all we can possibly do. And if we cover any potential functionality, it must be successful.

Level three: User Story is use-case

Here we finally got it. It’s about functionality slice, it should be INVEST. We have to make it concrete, understandable, and testable end to end functionality. Isn’t that easy? It’s like a use-case, isn’t it? Well, unfortunately, sorry to say that, no. There is a huge difference between use-case and User Story. So what’s the difference? Use-case is end to end functionality which defines what user does and how he is using the product, while the User Story defines only a new/changed functionality. We don’t repeat the current functions anymore and we focus on the changes only.
This stage is already user focused. We start describing different roles. We focus on functionality end to end. However, it’s still not simple and not clear enough. And it’s still not what we expect from the Product Owner.

Level four: We will design one big User Story and copy-paste the rest

This stage looks already pretty good. We have understood that every User Story has three parts – Who, What, and Why, and we think about all three of them. However, we haven’t still understood that every single User Story has its unique value, and it makes sense to invest an energy into individual detail User Story creation process. We are now spending energy describing Super User Stories (smaller and much more concrete pieces than Epics are, although nor small enough to be done in one Sprint yet.) We have great tools, which unfortunately offer a copy-paste feature. So we heavily use it to save our time.

This stage is about User Stories which already create some picture in your head once you read or hear them, but they are very similar to each other and hard to be recognized. We already have spent some time to investigate reasons ‘why’ for bigger chunks of functionality, and we are very happy about it, so we use it at every detail User Story which we create from it – just copy and paste.

Step five: Understand of business value and impact

Finally, we understand that it is worth of investing our time to every single User Story. And we are even looking at it more than once. We reprioritize individual User Stories and not only big Epics. Every User Story has a special role or persona. We have spent time and energy defining every one of them. We encourage ourselves to throw away or postpone User Stories already written, if they don’t match our product/release charter (vision, goals, success measures, timeframe).

We focus on business value and “maximizing work not done” which is one of the core Agile Manifesto twelve principles. We keep our product simple. We try to visualize business value for every User Story in the “Why” part of the formula, so that it helps us to decide on Backlog priorities.
Furthermore, we compare every new User Story with product/release charter and discuss how that User Story contributes to the defined goals and vision. Before we write the complete functionality, we try to measure impact, i.e. if the goal of Epic1 is to limit the traffic through the component A, than individual User Stories may propose different solutions how to filter that traffic out. In traditional management we finish most of them if not completely all. In this stage of this model, we try first to measure the impact by identifying of the percentage of possibly filtered traffic by each solution proposed. And then implement just the ones which have real impact with respect of our goal to limit the traffic. We may identify many great ideas, but we stop implementing as soon as the goal is achieved. At that time we don’t need any other functionality and we can move on to the next important area.

This final Product Owner Development model stage is about business value and impact. The less is more. Product Owner is feeling strong ownership and responsibility over the Product Backlog and individual User Stories. There might be people to help him as Product Owners rarely works alone, nevertheless he understands the importance of his role in defining even the small functional slices as User Stories are. Finally, in this stage the Product Owner is here to shrink possible functionality to the minimum which brings just enough business value. Product Owner must negotiate the functionality and focus more on understanding the customer real needs than all their wishes to come true.

Summary

To summarize it, Product Owner Development model is useful tool which helps you to understand where you are with your Agile Product management and product ownership. It also shows you the way where you shall continue and which areas you shall focus. Theoretically you don’t have to go through this model one by one, but it is very likely you will pass all next layers from the one where you are now even if you stay at that one just a very short time.