Writing user stories with the INVEST framework

March 31, 2016

My team does daily stand-ups, we write our requirements on user story cards (stored in JIRA of course) and that makes us Agile.

But does it really?

I don’t believe so. Agile seems to be the new black in the IT industry and many teams believe that as long they perform Agile rituals or use story cards, that makes them “Agile”. However, without actually conforming to Agile principles, teams will not reap the benefits that the Agile methodology brings.

One of the most common mistakes that I have seen is the way user stories are used. Too often, user stories are used by technology teams as a contract with stakeholders to show what “tasks” will be carried out as part of that piece of work. As a result of that mindset, the way the requirements are broken down and how the team tackles the work breaches the core Agile principle; “highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

Then that raises the question, how should a story be written?  And the answer to that question is that there is no hard and fast rule about how stories are written or structured. You do what is appropriate for your team and the nature of the project. However, you should always take the INVEST framework into consideration.

INVEST framework


Stories are independent and free from dependencies (where possible). Dependent stories make it difficult for planning.


Stories are not contracts. Stories serve as a reminder for a conversation where the features and details are discussed shortly before development.


Stories are valuable to the customer (the end user). It is common for developers to want to get things right one at a time (split the UI, logic layer and database into separate stories). The biggest problem with this approach is that each of the stories alone have no value to the customer without the other two. As a result, creating dependencies and making it impossible for the product owner to prioritise.


Stories are estimatable where developers and testers can take a guess at the effort required. If stories cannot be estimated, it is because there is a lack of domain knowledge, lack of technical knowledge or there are too many assumptions.  Consider doing a SPIKE or breaking the story into smaller stories.


Stories are small enough for a developer to complete in one full day (if possible). Smaller stories reduce the risk of defective and ambiguous requirements. Developers should be able to feel they have achieved something by the end of every day.


Stories are testable to verify that the value has actually been delivered.  If a story is untestable, how will a developer even know that they have done their part. Untestable stories often have ambiguous requirements. e.g. “Page will load fast”. Consider speaking to the product owner to define the word “fast” and reword the requirement to something like “Page will load within 4 seconds”.


Fictional Scenario: Our team has been asked to build an iOS mobile application for Groove Insurance Company. The application will allow their customers to get a quote on their car insurance. There is an existing mainframe which we will need to integrate with to retrieve the quote.

Agile project cards

*I have left out the story narrative (as a… I want… so…) to keep the example concise. Story narratives should be written when cards are fleshed out.

Following the INVEST framework during the elaboration of stories ensures your team is focused on writing code that is valuable and shippable rather than how much code is written. Getting into good habits when writing user stories will reduce the risk of arising problems such as:

  • Story is too big to estimate
  • Development team unsure which story can be played first
  • Product Owner doesn’t know what to prioritise
  • Ambiguous and missed requirements

As a result, your team will be the best prepared to adapt any adjustments in the business goals with minimal wastage.

For further reading into user stories and the INVEST framework, I recommend the book ‘User Stories Applied: For Agile Software Development’ By Mike Cohn.  This book is a phenomenal read for Agilists. It is something that I constantly find myself referring back to.



  1. Cohn, Mike. User Stories Applied: For Agile Software Development. Boston: Pearson Education, 2004. Print.
  2. Verwijs, Christiaan. “8 Useful Strategies For Splitting Large User Stories (And A Cheatsheet)”. Agilistic. N.p., 2013. Web. 17 Mar. 2016.
  3. “Principles Behind The Agile Manifesto”. Agilemanifesto.org. N.p., 2016. Web. 17 Mar. 2016.


Author: Tony Liu, Agile Business Analyst