...the Product Backlog is in place and the Product Owner is working on Product Backlog Items (PBIs).
✥ ✥ ✥
Unexplored requirements cause unpleasant surprises.
It's easy to throw requirements over the wall and say: "That requirement was covered." It's even easier in Scrum. Their user stories are enough. And the Agile culture encourages deferring decisions and a ready, at-hand on-site customer who can compensate for requirements lapses during development. Scrum acknowledges emergent requirements, and it's too easy for the business to claim that the real requirements will come out only when pushing on them during design.
There is a grain of truth in that observation. On the other hand, full-blown development is a heavy-handed way to elicit emergent 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. The business may be juggling many end users, and may have made concessions to some users that make things a little less attractive for other users. It's impossible to recover those decisions from users.
Much of Scrum depends on the team having a stable velocity. Once a system is designed, implementation effort can
usually be predicted with a high degree of confidence. Once analysis is complete, design and analysis can proceed without too many surprises. Most schedule surprises come from lapses in analysis. 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.
✥ ✥ ✥
The fact that the specifications are written down beforehand is much less important than that the Product Owner has done his or her homework. A written Product Backlog Item can serve as a testimonial 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.
Author: Jim Coplien, based on input from Jeff Sutherland