User Stories have been around for well over 20 years and have been the focus of various agile approaches. Its origins can be found in the development of Extreme Programming with a key focus being part of a ‘planning game’ for teams delivering products. Definitions of User Stories include:
“User Stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.” (https://www.mountaingoatsoftware.com/agile/user-stories)
“A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.”
“In consultation with the customer or product owner, the team divides up the work to be done into functional increments called “user stories.””
User stories have been a fantastic way for teams to take a more user centric approach to product development and help foster a conversation around the definition of products (typically software related). User Stories can be difficult for teams however to understand the true value of what they are producing. I’ve seen many stories been written in a user story format (e.g. ‘As A’… ‘I Want’ … ‘So That’) however when exploring what is the value to the customer or to the business, this can be hard to determine from the story itself. Teams can also get stuck on defining functionality due to the ‘I want’ part of the story done upfront, instead of digging deeper into the true value of what they are seeking to achieve.
Some teams try and address the question of value using some form of story sizing methods (e.g. Fibonacci sequencing, t-shirt sizing, etc.) for each story after the story is written. While the story is focused on the goal of the user (e.g. ‘I want’ or ‘so that’) what value is the story to the end user? How much value is the story to the business?
This is reflected to some degree in the Agile Alliance glossary for the definition of a story. Within its definition it outlines that to determine the value of a story requires ‘Advanced’ skill levels to be performed. Could there be another way which we could flip stories around to be focused on Value as the primary driver, not something which is either tacked on at the end (e.g. though value sizing) or only being able to be achieved after obtain advanced story writing experience?
Introducing the Value Story
Value Stories are similar to User Stories, however the key focus of these small increments of work are primarily based on the concept of Value.
The definition of value stems back to 1275-1325 middle English word of “valoir” (or Latin “valēre”) which was focused on doing something “of worth”. Cambridge defines it today as:
“The importance or worth of something for someone”
As outlined in the Agile principles, the concept of Value is a key focus, including the first principle:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
So if value is our primary goal, or as Jim Highsmiths Agile Triangle puts it, the top of the triangle, how can we focus teams at this end goal?
One format I’ve found quite useful for this is Value Stories. Here is a look at the template:
As a <Persona>
We value <this Outcome>
Measured by <Measurement>
This simple format refocuses any story to be a conversation around a measurable outcome (value) for an end-user, instead of the conversation being largely led by the solution. It flips the thinking for teams to be focused on measurable outcomes and value realisation.
The format can also be used by any type of business endeavor – not product specific, however service oriented. Value Stories can also have direct connection to business goals (e.g. OKRs) and can be split into smaller Value Stories.
Now over to you – Can you see it being used in your organisation? Keen to give it a go? Let me know in the comments below.