Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Product Owner should deliver Enabling Specifications

Product Owner should deliver Enabling Specifications

This item in japanese


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?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Just a few more steps

    by M Vleth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Let's bundle the 'enabling specs' upfront which makes estimates more accurate and enables stakeholders to know upfront what they get for their investment...

    If only we could give this a catchy name with some fluids and the steps to take...

  • Re: Just a few more steps

    by Steve Ropa,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    My thoughts exactly. Are we seriously saying that we need more "enabling specifications" because otherwise the Product Owner would have to <gasp> *talk to the team*?</gasp>

  • Business guys should try to clearly articulate what they want. News @ 11:00

    by Bruce Rennie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "Enabling specifications"?!? Seriously? C'mon, this is the kind of thing that makes the non-agile community roll its eyes.

  • Definition of Ready

    by André Faria Gomes,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think it is just another way of solving the problem that the Definition of Ready solves.

    I've been using it for some time, and one of the items of our "Definition of Ready" is that the user story must be clear enough for a team member to understand without much further need for clarification...


  • Requirements Definitions - don't forget them before coding it up

    by sukh nijjar,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Firstly, pulling in unclear stories into a sprint is going to cause you pain, the age old principle of understand the requirement still applies! A tightly defined acceptance criteria supplemented with business rules and concise key docs (maybe a wireframe or two, entity lifecycle model focusing on states key to the user story) will reduce the need for a constant dialogue seeking clarifications (and ‘crippling’ velocity). The 'downside' for sloppy teams is this isn’t a five minute activity and requires serious thinking and collaboration…upfront. Just in time analysis should not become last minute ad-hoc questions like some code first fanatics repeatedly fall foul off or misguided 'agile' development managers allow.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p