...the Product Backlog is in place and the Product Owner is working on Product Backlog Items (PBIs).

✥      ✥      ✥

Unexplored requirements cause unpleasant surprises.

The agile tradition is that user stories suffice as requirements artifacts, and early agile practice blindly believed in deferring decisions and in having a ready, at-hand on-site customer who could compensate for requirements lapses during development. Given this background, it’s easy for the Product Owner to throw ideas into the Product Backlog and think “that’s good enough.” Scrum can even support the Product Owner doing this because the Product Backlog is the Product Owner’s artifact so we assume they can do with it as they please. We also welcome emergent requirements in Scrum, assuming the Product Backlog will change as everyone connected with the product learns more, and this may also lead us to having poorly considered PBIs. Having the Product Owner collocated with the team is often assumed to obviate this problem but a half-baked idea is still a half-baked idea even if we socialize and review it.

Because Scrum acknowledges emergent requirements, it’s easy for the business to claim that the real requirements will come out only when pushing on them during design. On the other hand, full-blown development is a heavy-handed way to elicit requirements. Sometimes all that it takes is a bit of dialog between the business people and the developers, or between the end users and the Product Owner. Testers are notoriously good at sniffing out requirements lapses — lapses that are often easy to fill in (by talking to end users or other stakeholders) once they are discovered. And the further you get into development, the more difficult it becomes to engage end users.

So it’s good to do some up-front planning and to socialize proposals and open issues across all stakeholders. Scrum’s roots in Japanese manufacturing also bear out this focus on engagement and planning. But how much should be communicated from the Product Owner to the Developers, and how? A user story isn’t even a full requirement: it is just a statement of some stakeholders’ identities and their motivation behind some parts of what the system provides. They’re just one small part of “the requirements.” And while requirements help articulate a PBI’s contribution to the Product Vision, a requirement is not a definition of a product increment — it is only one insight on how that increment meets some isolated want or need. After all, it’s a Product Backlog and not a “requirements backlog.”

Most schedule surprises come from misunderstandings with roots in poor or poorly communicated analysis. Much of Scrum depends on the team having a stable velocity. Once a system is designed, implementation effort usually can be predicted with a high degree of confidence. Once analysis is complete, design and implementation can often proceed without too many surprises. Since estimation focuses on what happens within the Sprint, it’s important to move the uncertainty of analysis outside the Sprint — into the Product Owner process. If you don’t do this, the developers end doing analysis. That greatly slows velocity, and because the team is not expert in analysis or end-user and market perspectives, the requirements suffer as well:

Therefore:

The Product Owner should deliver Enabling Specifications as a sign that he or she has done due diligence in exploring the requirements space. Enabling Specification means that the specification is rich enough that someone reasonably skilled in the discipline can implement a solution without substantial subsequent clarification with people outside the Scrum Team. [1] says that part of the job of the Product Owner is “[e]nsuring the Development Team understands items in the Product Backlog to the level needed.ˮ

The Product Owner and Developers work diligently together to bring the Product Backlog to Ready (see Definition of Ready) in the weeks leading up to Sprint Planning, exploring all opportunities to create mutual understanding. But in the end the Product Owner is responsible to bring the Developers enough information so they have a clear understanding of what to build. The Developers have the final say over whether they have enough confidence to take a PBI into the Sprint for implementation.

✥      ✥      ✥

Enabling Specification in hand, the Development Team is prepared to create a Sprint Backlog based on a deep understanding of the upcoming delivery stream. If the Developers collectively do not believe that the Product Owner has communicated enough information to enable them to succeed in delivering the item, the Development Team will not pull the Product Backlog Item into a Sprint.

Establishing this understanding before the Production Episode starts helps the Development Team stay in “flow,” without having to interrupt development with the distraction of a meeting with the business. In the end, the specification must live in the collective mind of the Development Team; that something in a document meets some criteria of completeness is almost immaterial. The specification in the developers’ minds becomes enabling through interaction, explanation, prototypes, examples, and an exchange of questions and answers. A great Enabling Specification includes written test criteria so that test development is straightforward, and so there are objective criteria to support a ship / no-ship decision at the end of the Sprint. If the Enabling Specification isn’t good enough to specify how the product increment will be tested, it isn’t good enough to give the team honest confidence in how to build it. [2]

Of course, there are limits to perfection. If the Development Team finds itself in doubt about a Product Backlog Item while working on it during the Production Episode, then the Development Team and Product Owner should strive to resolve the gap at the earliest opportunity. The same applies if emergent requirements arise.

It is less important that the specifications be written down beforehand than that the Product Owner has done his or her homework, and that the team has thoroughly discussed the new item. A written Product Backlog Item can testify to the extent of that research. In fact, much of this research perhaps entailed discussions with the Development Team, suppliers, and partners, as well as market research, customers, and of course end users.

A single, passionate message and written Product Backlog Items alone aren’t enough. Research shows that managers are better respected and get their message across more effectively if they deliver it multiple times, often through different media, relying on redundancy to drive the message home. A good Product Owner will mix informal descriptions, user stories that underscore the user motivation, use cases that explore edge cases ([3], pp. 167-169), visuals that preview the user experience, prototypes that encode major expectations, and anything else that may open its own path to understanding that complements the others. [4] The Product Owner should socialize new items with the team as soon as they arise, at the earliest opportunity when the team is working towards a Refined Product Backlog. Each PBI can become more and more enabling at each backlog refinement effort and at each Sprint Planning event.

The phrase enabling specification is a term of law, applied as a standard for valid patents:

“A patent specification is enabling if it allows a person of ordinary skill in the art to practice the invention without undue experimentation.” [5]

A valid patent must serve to enable anyone reasonably skilled in the general area of the patent to be able to reproduce the invention from information in the patent alone without consulting the inventor. Analogously, the information that the Product Owner conveys to the team (whether in writing or not is immaterial) before the start of the Sprint should carry them through the Sprint in most instances, without need for further face-to-face consultation.

[1] Jeff Sutherland and Ken Schwaber. The Scrum Guide. http://scrumguides.org/scrum-guide.html, November 2017, Referenced 8 June 2018.

[2] Jeff Sutherland. “Enabling Specifications: The Key to Building Agile Systems.” ScrumInc.com, https://www.scruminc.com/enabling-specifications-key-to-building/, 2 June 2012 (accessed 5 January 2017).

[3] Gertrud Bjørnvig and James Coplien. “Enabling Specifications and Use Cases.” In Lean Architecture for Agile Software Development, Wiley, 2010, Section 7.1.2, pp. 167-169.

[4] Tsedal Neeley and Paul M. Leonardi. ‟Defend Your Research: Effective Managers Say the Same Thing Twice (or More).ˮ In Harvard Business Review, 89(5), May 2011. https://hbr.org/2011/05/defend-your-research-effective-managers-say-the-same-thing-twice-or-more (accessed 2 November 2017).

[5] Jay Dratler, Jr. and Stephen M. McJohn. “Obtaining Patent Rights.ˮ In Intellectual Property Law: Commercial, Creative, and Industrial Property, Volume 1, 1991, New York, NY: Law Journal Press, 2-231 § 2.07[6].

Picture credits: Adhesive Pads for Footwear (2008), United States Patent and Trademark Office, http://patft.uspto.gov/.