BT

Product Owner should deliver Enabling Specifications

by Anand Vishwanath on Apr 25, 2012 |

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?


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.

Tell us what you think

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

Email me replies to any of my messages in this thread

Just a few more steps by M Vleth

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

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

"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

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

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT