7

PRODUCT BACKLOG MANAGEMENT

A requirement is not a document. It exists whether it has been captured or not. It may not even be known yet. This adds to the complexity of developing a software product. The best you can do is to keep inspecting and adapting in an empirical way.

All requirements fall into one of these categories:

1. How/why someone uses the system 5 Functional

2. How the system should behave 5 Nonfunctional (stability, usability, performance, etc.)

3. The rules that surround the existing business domain (e.g., formulas, processes, laws, etc.)

The level of detail needed depends on your goal (see Figure 7-1). Is there value in the requirement itself? Or are you simply concerned with not forgetting something?

Figure 7-1 What is your goal for documenting requirements?

In some situations, the requirement document may have value to the business. If lives are on the line, you may need to specify more detail. Fixed price vendor contracts may need more documentation.

However, the reality of the vast majority of product development work today is that more value comes in representing stakeholder needs (or what they think they need) than in capturing detail.

Rather than worrying about requirements ambiguity and documentation, which in itself could be quite wasteful, strive to represent, or tag, the functionality.

Instead, consider creating a big to-do list for the product where the intent is not to capture detail; the intent is to not forget to ask all the right questions, either upfront or somewhere down the road.

Think about it: How much detail do you put into your personal to-do lists? Each to-do list item is nothing more than a reminder to get something done.

The details will be captured along the way, while you strive to better understand the underlying customer need, as acceptance criteria, tests, diagrams, conversations, and so on.

In Scrum, the Product Owner’s “to-do list” is the Product Backlog.

So what exactly do you put into a Product Backlog?

Figure 7-2 Valid Product Backlog items

As Figure 7-2 shows, the Product Backlog is open to all types of work:

Feature Requests: Any request from a stakeholder (e.g., “I want admin access.” “I want to be able to sort this list.”)

Nonfunctional Requirements: Qualities of the system (e.g., Performance, Scalable to 2,000 concurrent users, Legal Terms & Conditions)

Experiments: Functionality that is released to production to test the marketplace (e.g., New UI, User Survey, Analytics); also, experiments can be “enabling constraints,” as described in Chapter 5

User Stories: Placeholders for conversations; popular in the agile community

Bugs/Defects: Problems that have arisen from a previous release

Use Cases: List of actions between an actor and a system (not as common these days)

Capabilities: Different ways or channels to access existing functionality (e.g., mobile, web, cloud services, public API)

As a framework, Scrum does not prescribe any real method or template for Product Backlog items. However, the vast majority of Scrum Teams populate their Product Backlogs with user stories.

A common approach to capturing requirements was use cases. Use cases were originally developed and used by Ivar Jacobson in 1986. They became popular in the 1990s by practitioners of the Unified Process (UP) and Unified Modelling Language (UML). Use cases break requirements into more manageable pieces (scenarios) and describe a specific behavior from the context of an actor working with a system. They also provide a mechanism to get into a lot of detail, which if you aren’t careful can generate unnecessary documentation and actually reduce communication. The creation of a single use case could occupy a team for months before it is handed over for development.

Admittedly, use cases were never meant to be exhaustive documents. They were meant to be built iteratively as development was happening. However, too many organizations were writing tedious use cases that added little or no value and resulted in a lot of rework.

In an effort to fight back against the amount of unnecessary detail in use cases, user stories were introduced by the Extreme Programming community in the 1990s, with the intent to “force” brevity and create purposeful ambiguity. The idea is that this ambiguity would result in more face-to-face communication.

User stories are best explained with the Three Cs:³

Card: Legend has it that when approached by eager entrepreneurs looking for an investor, Andrew Carnegie’s standard response was to ask them to write their ideas on the back of their business cards. If he liked it, he would call them back. Given this opportunity, what do you suppose they would focus on?

One would imagine they would be desperately trying to communicate value and make it interesting enough for a follow-up conversation.

This same principle applies to user stories, which are commonly captured using a 3" × 5" card and a felt-tip marker. They are not the requirements. They are instead a tag that represents value to the business and a promise of a future conversation, the second C.

Conversation: Teams often say that the area that needs the most improvement is communication. By being purposefully ambiguous and intriguing, user stories are designed to increase conversations. This can be tremendously freeing when creating Product Backlogs and when new requirements arise. It allows you to not stress about the details right away and instead quickly jot something down as a placeholder for a future conversation, at which point you will fill in the details. The details are captured as the final C.

Confirmation: Rather than endlessly repeating the same conversations, agile teams capture details of a user story just in time. This detail is typically captured as acceptance criteria before a team takes on the story. Acceptance criteria is what the Product Owner, representing the stakeholders, deems as necessary to consider the story accepted.

A good rule is to limit the acceptance criteria to the back of the user story card. If more room is needed, the story may need to be broken into smaller stories.

A popular and simple template for user stories, first used by Connextra and popularized by Mike Cohn in User Stories Applied,⁴ is shown in Figure 7-3.

Figure 7-3 Popular user story template

As a <role/persona> (who?): The focus is on a stakeholder, not just a user. Keep in mind that not all value is directed at a user of the system. For example, a company’s lawyer would see the value in a “terms and conditions” user story, whereas it could be a distraction for an actual user. Try to identify specific roles from the business domain and avoid using generic roles like “user” or technical roles like “Product Owner,” “Scrum Master,” or “Developer.”

I want <behavior> (what?): This is a business-oriented workflow or action that describes the requested feature. You should avoid technical actions, such as “I want to create a database” or “I want to refactor that nasty piece of code.” These technical actions are solution oriented and should be done instead as part of a separate, more business-oriented user story.

So that <the value>) (why?): This is a crucial, yet often forgotten, part of a user story. The better you can communicate the reason for the requested functionality, the better decisions and assumptions will be made by all involved. If this seems challenging to create, then it may be telling you something about the validity of the user story.

Figure 7-4 provides an example.

Figure 7-4 Example user story

INVEST is a useful mnemonic established by Bill Wake in Extreme Programming Explored.⁵ It can be used to inspect the quality of your user story by validating it against each of the following (in Bill Wake’s words):

Independent

Independent stories are the easiest to work with. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.

You can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.”

Negotiable . . . and Negotiated

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we do not need these to prioritize or schedule stories.

Valuable

A story needs to be valuable. We do not care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these should be framed in a way that makes the customer perceive them as important.

Estimable

A good story can be estimated. We do not need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we do not understand. It is also a function of size: Bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience.

Small

Good stories tend to be small. Stories typically represent at most a few person-weeks’ worth of work. (Some teams restrict them to a few person-days of work.) Above this size, it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than month” often implicitly adds, “as I do not understand what-all it would entail.” Smaller stories tend to get more accurate estimates.

Testable

A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.

Another well-known acronym is DEEP⁶:

Detailed Enough—acceptance criteria to get started

Emergent—The Product Backlog is never “complete”; it is refined over time

Estimated Relatively—sized in terms of effort

Prioritized Ordered—by value, risk, cost, dependencies, etc.

Usability

Scalability

Portability

Maintainability

Availability

Accessibility

Supportability

Security

Performance

Cost

Legal and Compliance

Cultural

That is, they exist because of the fact that a system exists, as opposed to functional requirements, which may exist whether or not you have a system. For example, the need for depositing money into a bank account exists in the client banking business domain whether or not an ATM exists. But having an ATM introduces new nonfunctional requirements around security, accessibility, and usability.

In other words, functional requirements describe what the system should do, whereas nonfunctional requirements describe what the system should be.

Highlighting these nonfunctional concerns is important as they drive many key architectural decisions.

How do you capture nonfunctional requirements?

Capture your nonfunctional requirements in one of the following three ways:

1. As a Product Backlog item

As nonfunctional requirements do have direct value to the business, it is perfectly acceptable to capture them on the Product Backlog, possibly even as user stories as represented in Figure 7-5.

Figure 7-5 Nonfunctional requirement as user story

2. As acceptance criteria

Another option for nonfunctional requirements is to capture them as acceptance criteria for a particular Product Backlog item. That way, the nonfunctional requirement is completed as part of a larger functional item and may affect the effort needed to complete it.

For example, a functional “Login” Product Backlog item, could have the following nonfunctional acceptance criteria:

Login happens within two seconds.

Password is masked.

3. As part of the definition of “Done”

If the same nonfunctional acceptance criteria seem to apply across most of your Product Backlog items then consider anchoring it in the definition of “Done” as they are omnipresent.

For example:

All pages must load within three seconds.

Content must appear in both English and German.

Figure 7-6 Example of tying nonfunctional requirements to Product Backlog items

How large is too large?

One fairly widespread rule in the agile community is that if a story—a Product Backlog item—cannot be completed within one Sprint, then it is an epic. However, having just one big story in a Sprint is problematic: The success of the Sprint now hinges on the completion of that single story, so you put a lot more at risk. The other inevitable result is that all the testing for the story (and for the whole Sprint) will happen at the end of the Sprint. This unbalance of focus areas can create a lot of churn within the Development Team, making it more impossible to produce a bug-free “Done” increment within the Sprint.

So what can you do?

Figure 7-7 Epics broken down by story across architectural layers

Well, you break it down some more. A good number is to have between 6 and 12 Product Backlog items in the forecast for the Sprint. This also means that shorter Sprints will have smaller Product Backlog items. For a two-week Sprint, this means that every couple of days a Product Backlog item should be “Done,” which helps spread testing throughout the Sprint. Development Teams that can achieve this will realize that they should actually release within the Sprint instead of delaying value until the end.

How do you split a story?

This can be a challenge for many teams. Remember, Product Backlog items should be valuable to the customer, which means each story slice has to still demonstrate some value, however small. For this reason, stories that are broken down by technology component (UI, Database, etc.) are considered invalid (see Figure 7-7).

The best place to start is with the acceptance criteria. You will learn more about how to write acceptance criteria later, but for now all you need to know is that they are the conditions of satisfaction for the stakeholders, not just the user.

A Development Team along with the Product Owner should ask: “What are we going to demonstrate to prove this story is complete?”

The resulting answer should be a concrete list of items that the stakeholders deem valuable (see Figure 7-8). Therefore, each and every one can then be translated into its own separate story.

Figure 7-8 Simple example of breaking user stories down from acceptance criteria

When do you break down epics?

Remember the Three Cs of user stories? The purpose of the card is to have a conversation. Epics that are far down in the Product Backlog are likely not being talked about too much. As the epics move further up the Product Backlog, more conversations happen about them and are captured as acceptance criteria on the back of the card. Once that card starts to fill up with acceptance criteria—a sign that an epic is getting closer to the top of the Product Backlog—you break it down. This could likely happen during refinement or even Sprint Planning.

Let’s take a closer look at acceptance criteria.

Figure 7-9 Example of Product Backlog item with acceptance criteria

Here are three common ways of writing acceptance criteria:

Given    <a precondition>

When    <a user action occurs>

Then    <an expected result>

Good acceptance criteria should be SMART and SAFE:⁸

SMART

Specific—what is the outcome?

Measurable—how can the outcome be measured?

Attainable—is it attainable with the current setup (skills, technology, etc.)?

Relevant—is it aligned with the objective?

Time-Bound—at which point in time can the outcome be measured?

SAFE

Success—what is the success criteria for the Product Backlog item? For example, an ATM user receives a receipt of the transaction.

Advance—what has to happen before the success outcome can be reached? For example, an ATM user accepts the terms and conditions.

Failure—what could go wrong, and how can you cope with it? For example, an ATM user does not have enough money in his account—prompt for another amount.

Error—what are the error situations that are out of our control? For example, there isn’t enough cash in the ATM machine—display “out of service” message.

A spike is a research Product Backlog item whose goal is to learn more about what is needed to complete the requested functionality.

Spikes are typically very simple proof of concepts that are likely to be thrown away after they have served their purpose. The ultimate goal of a spike is to reduce risk through experimentation, allowing us to make better product decisions sooner.

A preferred approach is to both research and implement the Product Backlog item in the same Sprint. If both cannot be completed within the Sprint, then the whole Product Backlog item goes back on the Product Backlog, and the Development Team completes it in a future Sprint. The team is no worse off than if they had preemptively separated the story into different Sprints.

It is worth repeating that this focus on completing valuable quality increments every single Sprint is essential to the agility of Scrum Teams and the business as a whole. Each Sprint results in an Increment, which from the stakeholders’ point of view is “Done.”

While business priority is important, it is not the only variable that affects the order in which you pull things off the Product Backlog.

To properly order your Product Backlog, you need to consider many aspects:

Business Value

The value created from implementing the feature: revenue, cost saving, customer retention, prospect customers, and future opportunity. Features that map closest to the product vision likely rank highest here. Example: A “make payment” feature that generates direct revenue

Risk

The importance of a Product Backlog item in terms of exposure to a harmful situation. This includes both business and technical risk. The higher the risk, the higher it should be in the Product Backlog. Business risk example: A feature that must be implemented before a regulatory deadline Technical risk example: Implementing new technology on which a feature depends without knowing whether the technology solution will even work

Cost/Size

The cost of implementing a feature. This is mostly (but not exclusively) associated with the effort and time that the Development Team needs to build it.

Dependency

Regardless of value, risk, and cost/size, sometimes a feature cannot be done before another. These can be both business and organizational dependencies.Business example: An authentication feature that must be completed before anyone can use the more valuable features Organizational example: A feature that depends on another downstream team creating a service for your team to use

As you can see, many forces are at play. Consider the following formula:

By finding a way to enumerate each of these variables, you can create an order ranking system in which the higher the number, the higher the item will be in the Product Backlog (see Figure 7-10). Then make adjustments based on identified dependencies.

Figure 7-10 Value, risk, and size (cost) as dimensions for Product Backlog ordering

By focusing on smaller valuable features, you risk that the large yet valuable items get ignored. As these are likely the more strategic initiatives, identifying them and breaking them into smaller (right-sized) deliverables becomes an important part of refining the Product Backlog.

Items that are low value, low risk, yet cost very little (left side of Figure 7-10) should not necessarily be ignored either. Consider these as “fun-sized” and work on them if there is extra capacity or they can be taken by newer Development Team members who are still getting comfortable working with the product. Some organizations even open-source these items to other groups within the organization or even to the public.

Obviously, the risky items that have little value (the right side of Figure 7-10) should be ignored.

This formulaic approach to ordering could be a good start. Just do not consider it a magic formula to which you are bound. Ordering the Product Backlog is more of a nondeterministic problem. You shouldn’t strive for the best answer as it likely does not exist. Aim for a good answer and trust the empirical process of inspecting and adapting. A good Product Owner, with help from the Development Team, can use intuition and experience to order the Product Backlog just as effectively.

With this in mind, spending a lot of time ordering the bottom half of the Product Backlog can be considered somewhat wasteful. Focus instead on the order for the next few Sprints. Since you are refining as you go, the rest will work itself out.

Ordering the Product Backlog will open up many important conversations within your Scrum Team (and with stakeholders) that will clarify assumptions, misconceptions, and dependencies and thereby reduce accidental complexity. This process itself generates lots of value.

This formula may seem straightforward, but where do the numbers come from?

Other approaches use somewhat arbitrary numbers to indicate value, much like with relative effort sizing. The number range does not matter as much as getting stakeholders engaged and using the wisdom of the crowd. There are plenty of facilitation techniques for this, such as:

Business Value Game¹⁰

Use planning poker to estimate value instead of size

Buy-a-Feature¹¹

Innovation Game using money to purchase features

20/20 Vision¹²

Innovation Game for simple ordering of a Product Backlog

Thirty-Five¹³

Collaboration activity for ordering

Using these democratic and inclusive processes with stakeholders for assigning business value to Product Backlog items has two main benefits for Product Owners:

1. They get a better overall sense of what their stakeholders are thinking.

2. Their stakeholders feel more included and heard.

Remember that business value is not the only factor when ordering a Product Backlog. Risk, cost, and technical dependency also play their parts.

Risk may not even need to be considered for certain products, while others may want to give risk more weight and more ranges.

Imagine you have two Product Backlog items, PBI_a and PBI_b. PBI_a is more valuable to the business while PBI_b is cheaper but addresses a bigger risk. Which should you do first? Let’s apply the formula:

PBI_a → (25 value 1 5 risk) / 8 size 5 3.75 order rank

PBI_b → (15 value 1 10 risk) / 5 size 5 5 order rank

In this case, PBI_b ranks higher on the Product Backlog as it addresses a large risk and is relatively cheap to implement.

This can be a handy technique, but like everything it can be taken too far. As a Product Owner, are you now stuck with the order derived from this formula? Of course not. Like any tool, if it makes your job easier, then keep using it. If you want to move a few things around after the formula ranking, then feel free.

Keep in mind that this formula does not take dependencies into account. It may be a good idea to have your Scrum Team make a pass over the ordered Product Backlog to reorder based on technical and business dependencies.

Refinement is a great opportunity to revisit this ordering each Sprint.

A clearly communicated and shared set of expectations creates the transparency needed to avoid this problem.

Software is no different. Whether you purchase a software package, consume a product as a service, or implement against an external API, you have certain expectations about quality, performance, and support. These expectations define what it means to be truly “Done.”

What should “Done” include? The answer depends on the context. Good candidates are:

thoroughly tested

integrated

documented

releasable

Sound good? Well, how much testing? How much documentation? Is there a difference if you are building a dating website or a vital medical product? There is not one universal definition of “Done” for all possible products. However, you need to ensure that “Done” allows for continuous releases without disappointing your customers and other stakeholders and is clearly communicated and understood by all people involved.

This shared understanding, with the goal of transparency, is manifested in the definition of “Done.”

When do you get to “Done”? Scrum indicates that the Increment must be “Done” by the end of the Sprint. However, waiting until the very end to get to “Done” can be risky. A Development Team can hedge their bets by getting each Product Backlog item to “Done” throughout the Sprint. The moment a Product Backlog item meets the definition of “Done,” it is then considered part of the Increment. The sooner they can achieve this within a Sprint, the better (see Figure 7-11).

Figure 7-11 Continuously “Done” versus “Done” once at Sprint end

Consider this list of “Done” elements:

Unit tested

Code reviewed

Matches code style guide

No known defects

Checked into main dev branch

Public API documented

Acceptance tests pass

Product Owner approved

Regression tests pass

Release notes updated

Performance tests pass

User guide updated

Support guide updated

Security tests pass

Compliance documentation updated

At what point could your Development Team realistically do these? Every time they complete a Sprint Backlog item? A Product Backlog item? At the end of a Sprint for the overall Increment? Or will it have to wait until just before a release?

What if you placed them in a chart like the one in Figure 7-12?

Figure 7-12 Being “Done” more often reduces risk and promotes continuous delivery.

In an ideal world, all of these items would be completed at the Sprint Backlog item level. The introduction of practices like automation and the elimination of wasteful bureaucratic activities could make it a reality, but likely the extra effort could reduce your ROI, at least in the short term.

The further down the line you go in Figure 7-12, the more risk you introduce. Anything in the “Release” level is a huge risk, as you are indicating that those items cannot be addressed within a Sprint and would have to wait until right before a major release. So how far up the line can you push these activities? What can you do to move them up a level? If it takes two weeks to do regression testing, then likely you cannot complete it within a Sprint. However, delaying regression testing to the very end is risky. Your Scrum Team should be focusing on all the elements in the “Release” level and asking what practices they can put in place to move them up. In the case of regression testing, automation can make a big difference. But do not just settle for doing regression testing once a Sprint for the Increment. What would it take to get all the regression tests running every time the Development Team completes a Product Backlog item? Or what about every time a programmer checks in code? This is how a Scrum Team gets closer to continuous delivery.

So what’s the difference between acceptance criteria and the definition of “Done”? The definition of “Done” is for the whole Increment. Acceptance criteria are specific to a single Product Backlog item. To realize the value of a Product Backlog item, you must fulfill all of its acceptance criteria plus what is in the definition of “Done.” If you throw out the Product Backlog item, you also throw out its acceptance criteria. The definition of “Done” stays. In other words, the definition of “Done” is the global acceptance criteria.

The definition of “Done” addresses two aspects. One is what is required from a good engineering point of view, the technical aspects of the Development Team. The other, albeit smaller, aspects are domain requirements like regulations, laws, and so on. The latter need to be communicated to the Development Team so that they can figure out a way to address them correctly from their point of view (see Figure 7-13).

Figure 7-13 Division between technical and domain areas of definition of “Done”

How often does the definition of “Done” change? Again, it depends. Whenever there are new insights about the product and its quality, it is time to change the definition of “Done.” Usually more changes occur in the beginning since a lot of learning happens in the first Sprints, especially on the technical side. The domain aspect often changes whenever marketplace or internal/external regulatory requirements are introduced. Nonfunctional requirements (performance, usability, legal, etc.) often find themselves on the definition of “Done.” The definition of “Done” grows over time (see Figure 7-14).

Figure 7-14 Definition of “Done” growing over time

Think of the definition of “Done” as the code (as in rules, not programming) of quality that everyone commits to. Unlike professions such as doctors, plumbers, and accountants, the software development industry has no universally agreed-upon document to protect it when under pressure to deliver more, faster. At least when a Scrum Team (and the development organization) within a company sets its own standards of quality, they have something to point to when asked to do something that could compromise the quality of the product. As part of continuous improvement, the Sprint Retrospective is a good place to amend the definition of “Done.”

Barry Overeem:

Created design

Updated documentation

Tested

Approved by Product Owner

Clear on “how to demo” at Sprint Review

Francois Desrosiers:

Code review done

Unit tests done

BDD tests done based on the acceptance criteria

Documentation done (based on the documentation that the client defined as essential and valuable)

Features tested/approved by the PO or business analyst

Features deployed in the staging environment

Source code of the feature is in the proper branch

Jeronimo Palacios:

It works

Passes the acceptance criteria

It is in production

Peer reviewed

Covered by tests

Passes all the tests

Merged into Master

No apparent bugs

Accepted by the PO

API documented

Anything not trivial commented

Argument for binaries documented

Fredrik Wendt:

Everything is version controlled

Code reviewed

Automated tests setup

Solution shared with full team

Live/in production

Vincent Tence:

All automated tests pass

The application supports the expected load

Response time is within accepted limits

Manual tests are conclusive

Exploratory tests are conclusive

Development Team is satisfied with test coverage

The application has been translated to French and English

The application is accessible and available on all supported devices

Release notes are up-to-date and ready for publication

Online help is up-to-date with latest features

Ops diagnostic can be done efficiently and timely

Ops Team is confident they can operate and support the application

Revision history is exploitable

Development Team can set up a new development environment automatically

New key learnings and design decisions are documented

Development Team is satisfied with the new user experience

Codebase is in a better state than before

Development Team is satisfied with new code quality

Ops Team can roll back to a previous version retaining all data

Application is available in Pre-Production environment

No new security vulnerability has been introduced

Development Team can reproduce identical deployment

Ralph Jocham:

Compliant to development standards

Passes code analysis

Documented (Scenario, SAD, Test Case, Interfaces)

Reviewed or pair programmed

Automatic Unit Tests (for non UI, i.e. tier containing business logic has a test coverage of 95 percent or higher)

Automatic Selenium Tests; each usage scenario has at least one Selenium test

Automatic Appium Tests on target device

All text is internationalized

No known bugs exist

Figure 7-15 shows a useful definition of “Done” template for multiple teams working on one product. It defines common elements across the teams, but also leaves autonomy in how they work within each Development Team.

Figure 7-15 Definition of “Done” template

Look at it this way: Why do you change the oil in your car on a regular basis? Why do you check the pressure in your tires on a regular basis or bring the car in for service? As a driver, you only want to get from point A to B; that’s where the value is for you. However, if you do not pay regular attention to maintenance, eventually the negligence will catch up to you and will result in being broken down on the side of the road with high repair costs. It is the same for software. If you do not maintain it on a regular basis, you will accrue lots of technical debt—slowing development, reducing innovation, and costing far more in the long run.

For that reason, it is important for a Product Owner to understand the technical concepts of the definition of “Done” and be aware that they could have dire consequences in the long run. That is why you want to know about them and track them. If this is not already happening, then ask your Development Team to start measuring them and to maybe add the measurements into the automated continuous integration environment, which will let everybody know the moment the Development Team checks in any code that violates the definition of “Done.”

This is like being notified from your car dashboard the moment something goes wrong. Ultimately, a good definition of “Done” creates transparency for the Product Owner, the Development Team, and the stakeholders.

If you feed garbage into the Sprint, you most likely will get garbage as output.

In other words, if you are not “Ready” at the beginning of the Sprint, you won’t be “Done” at the end of the Sprint.

Mise en place is a French culinary phrase that roughly translates to “putting in place” or “everything in its place,” which refers to organizing your kitchen before you start cooking. Essentially you make sure that you have all the required ingredients in sufficient amounts, the right equipment ready to go, oven preheated, and so forth. Imagine halfway through baking your grandmother’s famous apple crumble pie you discover that you do not have enough apples. You would have to run out and buy more, but once you return the already cut apples may have turned brown. If you want raving reviews, that surely is not going to get you there. Once you put everything in its place and make sure you have the tools and infrastructure, you are ready to roll.

What is the equivalent in software product development? Well, it is not as simple as laying everything out in front of you. Software product development is complex, abstract, and less tangible. That means “Ready” is also less tangible. Even if the Product Backlog items have been broken down, estimated, and given clear acceptance criteria, you still may not know how to implement the Product Backlog item.

Jeff Patton includes a useful metaphor in his story-mapping book¹⁵ that emphasizes the importance of “conversation” in the Three Cs (card, conversation, confirmation). He tells a story about showing a vacation picture to a friend, a picture like the one in Figure 7-16 showing Ralph and a few friends on vacation.

You see a photo of Ralph being surprised by a handful of colorful birds. For Ralph, it is more. It is a memory he can relive by looking at it. He was there to experience the moment, the location, the story about how the birds found him, the sound of the birds, the noise they made (they were deafening), their smell (they were pungent), and their rather sharp claws that left scratch marks on his skin that remained visible days later.

Figure 7-16 Ralph on vacation with birds

For the rest of us, it is just a photo; for Ralph, it is a vivid memory. That is what Product Backlog items are. Think about them as memories you create for each Development Team member. Apart from the size, estimate, and acceptance criteria, it does not matter that much what is written on the card. What matters is the narrative behind the card. Put enough on the Product Backlog item card to remember, but make sure the narrative sticks so that it can be recalled if it becomes part of the Sprint Goal.

In other words, getting a Product Backlog item “Ready” is about communicating the story behind the picture in a way that the Development Team can act on it.

1. Small enough to be completed within one Sprint

2. Sized so that you can get an idea about the overall effort of the whole Product Backlog

3. Just enough detail (acceptance criteria) so that it can act as confirmation that the Product Backlog item is functioning as intended

On top of that, you may even refer to architectural constraints, business rules, UX designs, dependencies, and more, based on the needs of the product and the Scrum Team.

None of this has to be perfect. The Development Team just has to know enough to make a forecast in Sprint Planning. This may vary from Scrum Team to Scrum Team.

Scrum does not define the concept of “Ready.” The Scrum Guide considers Product Backlog items that can be “Done” within one Sprint as “Ready.” Why? “Done” is a black-and-white checklist; you can check each point off with a yes or a no. One or more no’s mean that you are not fulfilling the definition of “Done” and are not releasable. “Ready,” on the other hand, is not a checklist but a helpful guide during refinement that may not always be achievable. Defining “Ready” should not mean that a Development Team cannot attempt a Product Backlog item that is not 100 percent “Ready.”

The important thing is that “Ready” is a mindset, a common understanding to be reached within the Scrum Team. It doesn’t matter whether the content is in the form of a user story, a sentence, or a rough sketch. What does matter is that each Development Team member understands the intention of the Product Backlog item and feels good about starting it. So on top of the three points shown earlier: small enough for one Sprint, sized, and just enough detail, consider a fourth point:

4. Understood by the Development Team

Once this state is reached, feel free to make the Product Backlog item part of your Sprint Goal.

Figure 7-17 Using a “Ready” line for Product Backlog items

Instead of being driven by activities like planning, analysis, design, implementation, and testing, where your batch size is the whole product, it is good to have a Product Backlog that allows you to think in value. That is one reason it is important for the Product Owner to always keep the Product Backlog ready and ordered. The Product Backlog is emergent, so that the details come into focus as the Scrum Team works through it. The longer they can wait, the better decisions they will make.

This essentially means that the first reasonable moment to make a decision is the last responsible one.

This enables you to keep the unknown-unknowns, the complexity, vague for as long as reasonable. But once the time is right, you go deep. You go from a “mile wide and inch deep” to “an inch wide and a mile deep.” You do this just in time and then go ahead and create another Increment with exactly what you specified a little earlier. This way you delay to avoid creating waste.

In other words, have just enough of your Product Backlog “Ready” for the next few Sprints. Anything else is considered waste.

Lean manufacturing or lean production, pioneered by Toyota, is a systematic method that minimizes waste without sacrificing productivity.

Lean defines seven areas of waste. An easy way to remember them is by thinking of wasteful TIM WOOD, as outlined in Table 7-1.

Table 7-1 TIMWOOD Mnemonic Device

Anything that does not add value is considered waste. In Japanese this is called muda. Lean differentiates between two kinds of muda:

Muda Type I—Non-value-added activity, necessary for product or customer. For example, compliance documentation.

Muda Type II—Non-value-added activity, unnecessary for product or customer. The aim is to eliminate this type of waste.

Story mapping, originally developed by Jeff Patton,¹⁷ is a powerful tool to discover the right solution for your users and evolves as you gain insights. It is the process of visualizing your product from the initial vision, to user key activities, and viable releases (see Figure 7-26). A story map becomes a multidimensional map that tells the story of the overall product and provides a development strategy for fast learning.

Figure 7-18 Structure of a story map

Think outside the box to come up with cool product ideas.

What are the variations the users expect from the product?

What are the exceptional paths for all the things that can go wrong, and how would the user recover?

Are there other users, and how would they like to use the product?

The short answer is perfectly. As described in the Product Backlog section, the Product Backlog reflects all the work the Development Team needs to do. The Product Backlog is a one-dimensional priority queue. The story map expresses the vast amount of work from the Product Backlog in more than one dimension. What the Scrum Team needs to do is to project the story map into your Product Backlog (see Figure 7-19). The resulting order has to reflect what best maximizes value generation, risk mitigation, and technical dependencies for fast learning.

You may also discover constraints, which is work that slows or halts other Product Backlog items (or user stories) from being completed. Constraints could be technical or something else.

Figure 7-19 Story map projected into Product Backlog

1. No big picture (vision)

2. No learning (validation)

How does impact mapping address these points? Impact mapping is a strategic planning technique that prevents companies from getting lost while building a product. Each assumption is clearly communicated. Each of the team’s activities is clearly focused and aligned toward one of those clear business objectives. As each activity is clearly directed toward an objective, it can be measured and validated while working on it. This allows for more effective roadmapping.

On top of this, working in Sprints with “Done” Increments at the end of each Sprint facilitates ongoing learning about what the Scrum Team builds and how they work together. This covers customer feedback, scope, tests, integration, and many more elements. This feedback allows for validated learning. Those learnings in turn drive the scope and roadmap.

This approach of having a clear vision and thinking in value with the measurable business objectives based on continuous validation allows you to deliver even large interdependent products in an environment of constant change.

Also, as all decisions are being validated, this process leads to better choices regarding the roadmap and the scope within, which in turn causes less scope creep and waste along the way.

In his popular book Start with Why,¹⁸ Simon Sinek makes the strong argument that you should always start with “Why” as described in his Golden Circle (see Figure 7-20).

Figure 7-20 Golden Circle

Impact mapping builds and extends this thinking by using the “Why” to identify the right scope and how to validate it. This is achieved by adding the question of “Who” is going to benefit (see Figure 7-21).

Figure 7-21 Impact mapping driven by the person being impacted

If “Why” is the goal you want to achieve along with a value metric to validate the business objective and the “Who” is the actor performing the act, you can identify “How” you can achieve this impact. Once the impact is identified, you can come up with “What” is needed. This is your deliverable. The resulting impact map allows you to compare the various options and measure the outcome (see Figure 7-22).

Figure 7-22 Impact map example

Each deliverable in turn can be broken down into tangible Product Backlog items, in the form of user stories, for example (see Figure 7-23). Given that the goal, the actor, and the deliverable are established, defining the Product Backlog items is more straightforward.

Figure 7-23 Product Backlog item as user story from impact map

Figure 7-24 Success criteria as measure of impact validation

Think about a measure and how it will validate your targeted impact. This practice is useful as it enforces defining value validation measures and the resulting metrics upfront. This is a good mechanism to tie your measures back to your EBMgt metrics: in this case, customer happiness.

Figure 7-25 shows a way of making this transparent by creating a different view of your Product Backlog

Figure 7-25 Assigning Product Backlog items to impacts

Each Product Backlog Item gets associated with an impact, and each impact has a clear measure for validation. By having the Product Backlog item sized, it helps to derive the anticipated overall effort and resulting cost.

The goal is to have each Product Backlog item associated with an impact. There may be some work that cannot be associated. That is acceptable as long as you can still justify its existence, which could lead to newly discovered impacts.

SPECIFICATION BY EXAMPLE

Let’s break that quote down. Formality does not mean that you drill down with a big upfront design effort to specify everything in the Product Backlog. It means that you remove enough ambiguity from a Product Backlog item just in time to be “Ready” for it to be developed with minimal waste.

Requirements have a tendency to be abstract. At the beginning, this is a good thing as it leaves your options open while you are deriving scope from rather broad goals or a product vision.

However, the further a Product Backlog item moves up the Product Backlog, the more it needs to be “Ready” to be consumed within a Sprint. By the time a requirement has tests written for it, it becomes much more precise (see Figure 7-26). This is where tests and requirements become indistinguishable. Once there is something as precise as a test, why is the requirement needed anymore? The test is the requirement and the requirement is the test. Eliminating the need for separate requirements reduces waste. As tests are constantly being executed, they are much more likely to be kept up to date than a requirements document.

Figure 7-26 Different levels and granularities of “Ready”

At the same time, the human brain is not that great at dealing with lots of information at once. This means that when you do need more precision, it should be done just before putting the effort into developing it.

You get to that level of precision by breaking down a requirement into all possible scenarios and by illustrating them. Each scenario will be illustrated with at least one concrete example and more if needed. This process of illustrating is a team effort so that all relevant perspectives are considered. The resulting examples then guide the Development Team to implement the requirement—and these examples also guide the testing effort. Both development and testing get the information from the same source. You succeed in removing all ambiguity by having tests as requirements and requirements as tests. In other words, executable requirements.

Once you reach this level of precision, it is fairly easy to automate them in a meaningful way. Specification by Example exploits this formality and formulates requirements by writing automatable tests. These automated tests can then function as executable documentation (see Figure 7-27).

Figure 7-27 Examples driving requirements and tests²⁰

Examples sound nice, but how do you get there? Get familiar with the concept of the Triad.²¹ The Triad is made up of a representative for each the following domains:

Business

Development

Testing

In Scrum, these roles would be covered by the Product Owner and/or a subject-matter expert for the business domain, and a programmer and tester from the Development Team. As you can see, these three domains can be easily covered by a cross-functional Scrum Team. Together, they will refine and illustrate the requirements and all acceptance criteria with specific examples.

Consider the Triad to be the amalgam between the why and the what from the business perspective and the how from the development perspective. Therefore, on the Agile Testing Quadrants, described first by Brian Marick²² in 2003, they reside in Quadrant 2 (see Figure 7-28). With the evolution of agile, Quadrant 2 has emerged as the most important area for testing.

Figure 7-28 Agile Testing Quadrants and the Three Cs or Triad

The benefits of using Specification by Example and to illustrate the requirements with examples are numerous.

This tight collaboration between the three domains is a great antidote for misunderstanding. It prevents bugs and subsequent bug fixes. This leads to less rework, higher product quality, and faster turnaround times.

Also, often not as obvious, it allows for concurrent work on Product Backlog items within a Sprint because of better alignment of the activities of the various roles like programmers, testers, and business analysts in the cross-functional Development Team.

Ultimately, Specification by Example gets all on the same page. Everyone may think they know what is meant by acceptance criteria such as:

“When users log in with invalid credentials, they should get a warning message.”

In reality, that statement could mean entirely different things to different people. Invalid password? Invalid e-mail? Incorrect role? No password? Too many attempts? What message? The same message every time?

Simply asking, “Could you give me some real examples that you would try to prove this works?” could resolve much ambiguity. Table 7-2 presents such examples.

Table 7-2 Specification by Example example

These examples are of data that you would need to gather at some point in the development of this particular feature anyway (while writing unit tests, adding test data, exploratory testing, etc.). Pulling at least some of this data together earlier in the development cycle is the essence of Specification by Example. These are no longer tests, they are executable requirements.

There are plenty of opportunities within Scrum to create and expand these examples. Product Backlog refinement, Sprint Planning, or even during the Sprint when the Development Team starts work on a new Product Backlog item.

Figure 7-29 Life science Specification by Example example

Think about the Specification by Example development flow the following way: First you create the high-level Product Backlog item, a user story, for example. This user story then gets refined and illustrated with examples until it is considered “Ready” and becomes part of the Sprint forecast. Then each example gets turned into an automated functional test,²³ and for each of the tests, the functionality is developed, driven by unit tests (aka TDD—Test-Driven Development) as in Figure 7-30.

Figure 7-30 Putting Specification by Example and Test-Driven Development together

____________________________

1. Merriam-Webster Collegiate Dictionary, 10th edition.

2. Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2017), 15.

3. Ron Jeffries, “Essential XP: Card, Conversation, Confirmation,” RonJeffries.com, August 30, 2001, http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/.

4. Mike Cohn, User Stories Applied (Boston: Addison-Wesley, 2004), 135.

5. William C. Wake, Extreme Programming Explored (Boston: Addison-Wesley, 2002).

6. Mike Cohn, “Make the Product Backlog DEEP,” Mountain Goat Software (blog), December 14, 2009, https://www.mountaingoatsoftware.com/blog/make-the-product-backlog-deep

7. Cucumber Ltd.’s homepage, accessed March 1, 2018, http://cucumber.io.

8. This acronym was first defined by Jef Newsom, one of the founders of Improving Enterprises.

9. “The DSDM Agile Project Framework (2014 Onwards),” chap. 10, Agile Business Consortium, accessed March 15, 2018, https://www.agilebusiness.org/content/moscow-prioritisation.

10. “Business Value Game,” agile42, accessed March 1, 2018, http://www.agile42.com/en/agile-coaching-company/agile-scrum-tools/business-value-game/.

11. “Buy a Feature,” Innovation Games, accessed March 1, 2018, http://www.innovationgames.com/buy-a-feature/.

12. “20/20 Vision,” Innovation Games, accessed March 1, 2018, http://www.innovationgames.com/2020-vision/.

13. “Thirty-five,” TastyCupcakes.org, accessed March 1, 2018, http://tastycupcakes.org/2012/10/thirty-five/.

14. Schwaber and Sutherland, Scrum Guide, 18.

15. Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product (Sebastopol, CA: O’Reilly Media, 2014), https://jpattonassociates.com/user-story-mapping/.

16. Agile Glossary Definitions, s.v. “last responsible moment (LRM),” Innolution.com, assessed March 1, 2018, http://www.innolution.com/resources/glossary/last-responsible-moment-lrm.

17. Patton, User Story Mapping, https://jpattonassociates.com/user-story-mapping/.

18. Simon Sinek, Start with Why: How Great Leaders Inspire Everyone to Take Action (New York: Penguin Group, 2009).

19. Robert C. Martin and Grigori Melnik, “Tests and Requirements, Requirements and Tests: A Mobius Strip, IEEE Software 25, no. 1 (2008): 54–59.

20. https://less.works/less/technical-excellence/specification-by-example.html.

21. The term “Triad,” created by Ken Pugh, is a more common term for the “Three Amigos,” created around 2009 by George Dinwiddie.

22. “My Agile Testing Project,” Exampler Consulting, August 21, 2003, http://www.exampler.com/old-blog/2003/08/21.1.html#agile-testing-project-1.

23. Often this is called ATDD (Acceptance Test-Driven Development).