Writing Detailed Product Requirements without Killing Creativity: thoughts on Nate Udren's excellent post on an "Outcome Oriented Backlog"

By complete accident, today I came across this thoughtful post on Medium.

See: https://medium.com/tribalscale/balancing-detail-and-value-in-your-product-backlog-7217bf3fa7f9

Beautifully written by Nathan Udren of Tribalscale, it explains clearly and simply how one might approach structuring Epics and User Stories in a Product Backlog in such a way as to facilitate and enhance team creativity within the development.

As he argues, if one relies on each User Story to fully convey what it contributes to the product then you run the risk of over-specifying the Story. Whereas if you keep the User Story deliberately simple then you lose a lot of the context necessary to understand the Story's higher-level purpose for the user.

Clearly, neither are helpful scenarios for product teams and arguably both lead to the same result – i.e. the development team runs the risk of losing focus on the wood for the trees. 

By contrast, in his view if you consciously relate all the User Stories up to a higher level of User Outcome (via Epics), then it is so much easier for everyone in the team to instantly understand the purpose of this or that User Story in a user-driven context. And he calls this an “Outcome Oriented Backlog” – which essentially specifies the hierarchy of Product Backlog relationships that tie the following agile artifacts together (in a “traceability matrix”):

• a USER OUTCOME <is composed of 1 or more>
• EPICS <which are composed of 1 or more>
• USER STORIES <each of which have detailed>
• Acceptance Criteria <written in the Gherkin format>

***

Arguably, what Nathan is saying is nothing new, but I personally think it proposes something that has real and substantive value in product management.

The key point that he is making is that by consciously linking User Stories to User Outcomes then a technical team developing a product can more easily and readily “get” how this or that User Story is contributing to the wider value context.

And equally, it also has the virtue of the product manager not having to over-describe each User Story. By keeping it loose and simple at the level of the individual User Story a product manager/owner allows the development team significantly greater creative latitude as to how they choose to implement the Story.

***

So IMO this is an awesome post, and I thoroughly enjoyed reading it. 

A bit detailed for a LinkedIn post, I know, but nevertheless genuinely interesting (to me, at least!) as I have directly come across these types of “specification” issues myself. And as I no longer use Twitter on a regular basis I thought I might as well post it here.