Invest in Better User Stories

May 30, 2019
Categories: Corporate
Reading Time: 3 minutes

Written by Josh Ettwein, Director of Software Engineering, MatrixCare

We all know the common format of user stories: “As a [role], I want to [goal], so I can [value].”, But this simple 11-word sentence causes so much angst among Agile teams the world over. Why is this? In large part, it is because the user story is the basis of all of the work we do. They are the primary input mechanism from the Product Owner to the team, and they are the driver of what we get done as a team. Additionally, we use them to regulate the “doneness” of our product’s features. As a result, is important to write “good” user stories, and I find that this topic comes up again and again with every team I talk to, regardless of experience level, size of the company, etc.

When I’m working on a team that is struggling to write good user stories, I like to remind them of the need to INVEST in their user stories. I don’t mean investing money or time, but instead remembering the INVEST acronym.

INVEST is as follows: Independent, Negotiable, Valuable, Estimable, Small, Testable.


While it is sometimes a lofty goal, in general, user stories should be as independent as possible. I like to consider “independent” to mean in terms of the order of completion. The reason this is important is that unless stories can be worked on in any order, truly valuable stories that have dependencies may be impossible to work on without the potentially less-valuable stories being worked on first.


A user story is not an edict, but rather a “conversation starter” of sorts. The story does nothing more than capture the gist/essence of what the customer (or via a customer proxy like the Product Owner/Manager) intended and open it up to collaboration and discussion. The Product Owner, developer and QA person at a minimum need to be involved so that we wind up with “works as intended” rather than “works as coded.” When in doubt, ask yourself, “how will I know when I’ve completed this story?”. If there is no clear answer to that question, you absolutely should not be working on that story; it needs more discussion.


Remember the format of good user stories? “As a [role], I want to [goal], so I can [value].” Well, the important part here is the “so I can [value]” bit. This is the user/business value of the story. If a story has no business value, it should not be worked on. Period. End of story. Hopefully, your user stories are constantly being organized in the Product Backlog to maintain hierarchy as it relates to business value so this one should generally take care of itself.


A good user story must be able to be estimated in terms of the level of effort to complete the work involved. If not, then this may mean that the story should be broken up, but I say, “may” because in many cases, the story cannot be broken up and requires more discussion to estimate correctly. The goal is to provide the smallest amount of information/direction in the initial story to invite conversation, but enough to be estimable.


This one pretty much speaks for itself, but it bears mentioning. I generally like to use two-week sprints, and this typically dictates user stories that are (on average) 3- 4 days of total work to get to a “done” state. Don’t fall prey to the temptation to “gold plate” stories. When they’re done, they’re done. Do the simplest thing that works and then stop. We’re looking for the “minimum effective dose” in medical terms.


In order to be considered “done,” every single user story must be testable to that effect. One good way I’ve adopted of measuring testability is to ask the question, “can I write acceptance criteria for this right now?” If the answer is no, then it’s likely that this is not going to be testable in its current state. I’m of the firm opinion that QA should be moved as far up into the front end of the process as is humanly possible, so getting feedback from QA on the “testable” aspect early-on is critical.


Hopefully, this has been a good reminder/refresher on the INVEST acronym and what it means for your team. Take the time to evaluate your process and INVEST in success!

Want to learn more? Let’s connect!

Josh Ettwein
Josh Ettwein

Josh Ettwein has served as Director of Software Engineering at MatrixCare for the past four years and is a highly pragmatic technology leader with a focus on delivering high-quality, intuitive software using agile practices. Josh is interested in building innovative products and services, and creating and growing great engineering teams. In the past, Josh has provided engineering and product development leadership on development of large-scale web, mobile and SaaS-based platforms, using a variety of technologies and languages.

Back to blog
Share this page

Learn more about how our services can help you succeed.