User Stories Should Be *Negotiable* User Stories are not a contract. They are not meant to be precise, detailed specifications of a feature. They should not be fixed in stone.

I recently quoted the ‘Invest’ acronym as a way to remember and assess what makes a good User Story.

The *N* in ‘Invest’ stands for Negotiable.

A User Story is a reminder. A reminder to have a conversation about a feature. A reminder to collaborate in order to understand the details just in time for the feature to be developed. Notes can be made on the User Story Card as details are captured and clarified.

A User Story should have sufficient information to capture the essence of a feature without requiring too much collaboration for the basics.

However, a User Story should not contain too much detail. Too much information can imply that the User Story is complete and precise.

So much more information can be gained from a conversation because of the rich, two-way nature of a verbal exchange. Too much information on a User Story can cause people not to collaborate, believing they already know everything they need to. Then you lose out. You lose out on the advantages of combining a written reminder with a verbal, face to face communication.

One of my 10 key principles of agile development is that ‘agile requirements are barely sufficient‘. Suffient. But barely. No more information than is necessary to proceed with development and testing with reasonable efficiency.

Sometimes a requirement may have been ‘specified’ in a particular way, and a developer finds that it’s awkard to implement. Or that there’s an easier alternative. In these cases, a small compromise, or a slight change in approach to the feature, can simplify and speed up the implementation. User Stories should be Negotiable, so no time is wasted when the user or customer’s goals can be met an easier way.

So, using the ‘Invest’ acronym, how does my recent Example of a User Story look in terms of being Negotiable?

Perhaps it’s a bit detailed? It implies a particular design approach to the functionality behind the button. Although this is really just a note about a key decision for the design approach that should be adopted; there is no detail on the design of the feature itself.

The visual approach implies a specific screen layout, although it’s meant to be a wireframe rather than a screen shot. Personally speaking, as long as people treat it as Negotiable, I think a picture is worth a thousand words and this is well worthwhile.

This example is possibly as detailed as a User Story should really need to get. Certainly I wouldn’t expect to see every User Story as detailed as this. Many User Stories could probably be described with less detail. And still be (barely) sufficient.


Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
145 City Rd
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at