Jeff Sutherland recently suggested that the user story should be an enabling specification that allows teams to operate efficiently without the need for continued dialogue with the Product Owner.
A user story must be an enabling specification for agile teams to operate at peak performance. If it is not, there will be the need for continued dialogue with the Product Owner during the sprint to figure out what the story means. This will reduce story process efficiency and cripple velocity.
Enabling Specification has been published as a Scrum pattern. Jim Coplien highlights the role of a Product Owner in delivering these specifications.
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.
Timothy D Korson further describes the importance of continuous requirement elaboration and Product Owner engagement.
When I'm a PO, I require that for every product backlog item (PBI) pulled into the sprint, an acceptance criteria/test scenario development task go on the task board. As PO, I remain engaged with the person doing that task and personally sign off on the resulting test scenarios. Any other team member working on that PBI is careful to remain engaged with us. A company in Chattanooga, Tennessee, that recently implemented this suggestion claims that it is an important improvement to its Scrum process and that it has given POs a chance to provide feedback even earlier in the development process. Reviewing the test scenarios as early as possible has helped them catch deficiencies in understanding sooner, resulting in less rework and improved productivity
In his book Specification by Example, Gojko Adzic suggests expressing specifications as executable tests which are understandable by non-technical stakeholders.
Traditional documentation gets out of date very quickly. Having programming language code as the only reliable source of truth on functionality creates information bottlenecks and black holes. This is where the long-term effects of well-written specifications with examples really come in. As the validation of these specifications is automated through acceptance tests and they run frequently, we can trust that the system does what these tests specify or from the other side, these documents still say what the system does. Well-written specifications with examples will be easy to read, access and understand, so they help us remove information bottlenecks.
Siddhartha Govindraj stresses on regularly validating the work against product goals.
So it is rather surprising that many agile teams have their sprints and acceptance criteria and definition of done, but have no techniques to validate the application against goals and change direction. In essence, they are playing the “requirements specification is God” game all over again.
If you are a product owner, then your job is NOT to simply to accept or reject stories, but to keep validating the product being built against goals and steer the ship.
Do you write enabling specifications or other forms of acceptance criteria for user stories? Does it help improve the efficiency of your development team?