New to agile? INVEST in good user stories

Bob Hartman 2009-05-14
30 Comments
Post Views: 53,660

As a <user> I want <function> so that<value>.

Above is a very simple user story template.  How can something so simple be so hard to get right?  User stories make up the heart of agile development.  They are the primary input to the team.  The team takes the user stories and creates product increments based on completing those stories.  Unfortunately, getting user stories “right” is difficult to do right away.  The Product Owner (or other product facing role) needs to learn how to create user stories which meet the needs of the team.  This is a skill which can be learned over time, but I’m about to save you a bit of learning curve.

In order to create good user stories, start by remembering to INVEST in good user stories.  INVEST is an acronym which encompasses the following concepts which make up a good user story:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Let’s cover each of them with a simple explanation.

Independent:  Stories should be as independent as possible.  When thinking of independence it is often easier to think of “order independent.”  In other words, stories can be worked on in any order.  Why is this important?  It allows for true prioritization of each and every story.  When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.

Negotiable:  A story is not a contract.  A story IS an invitation to a conversation.  The story captures the essence of what is desired.  The actual result needs to be the result of collaborative negotation between the customer (or customer proxy like the Product Owner), developer and tester (at a minimum).  The goal is to meet customer needs, not develop something to the letter of the user story if doing so is insufficient!  Remember, you can always ask the magic question to help drive the conversation.

Valuable:  If a story does not have discernable value it should not be done.  Period.  Hopefully user stories are being prioritized in the backlog according to business value, so this should be obvious.  Some people say each story should be valuable to the customer or user.  I don’t like that way of thinking because business value encompasses more than just customer or user facing value.  It includes internal value which is useful for things which are normally called “non-functional requirements” or something similar.  I prefer to say the story has value to the “user” in the user story.  In this way it is clear who is to be satisfied.  Finally, remember the “so that <value>” clause of the user story.  It is there for a reason – it is the exact value we are trying to deliver by completing the story!

Estimable:  A story has to be able to be estimated or sized so it can be properly prioritized.  A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it.  What happens if a story can’t be estimated?  You can split the story and perhaps gain more clarity.  Sometimes splitting a story doesn’t help though.  If this situation occurs it may be necessary to do some research about the story first.  Please, please, please timebox the research!  If you do not, it will take all available time thereby depriving the product of something else which could have been done instead.

Small:  Obviously stories are small chunks of work, but how small should they be?  The answer depends on the team and the methodology being used.  I teach agile and suggest two week iterations which allow for user stories to average 3-4 days of work – TOTAL!  This includes all work to get the story to a “done” state.  Also remember not to goldplate user stories.  You should do the simplest thing that works – then stop!

Check out our extensive resources on how to split user stories.

Testable:  Every story needs to be testable in order to be “done.”  In fact, I like to think of testable meaning acceptance criteria can be written immediately.  Thinking this way encourages more collaboration up front, builds quality in by moving QA up in the process, and allows for easy transformation to an acceptance test-driven development (ATDD) process.  As with negotiable above, asking the magic question can help ensure the user story is testable as well.

If Product Owners and their teams work together to INVEST in good user stories the learning curve of working together will be much shorter.  INVEST encourages good habits which eliminate some of the bigger problems of user stories like dependencies, being too big, hard to test, etc.  Take the time to INVEST in good stories and see the dramatic change in how effective planning will become, as well as how productive the team will become.

Until next time I’ll be INVESTing in good user stories because doing so definitely helps in Making Agile a Reality™.

Categories: Agile Ideas, Newbie, Planning, Practices, Product Owner, Tips
Bob Hartman
Known as Agile Bob, brings over 35 years of experience and broad industry knowledge cultivated by serving in almost every role in the software industry including developer, tester, documentation writer, trainer, product manager, project manager, business analyst, senior software engineer, development manager and executive. Over the past 20+ years Bob has grown from being an early adopter of Agile to his current status as a Certified Scrum Trainer® (CST) and Certified Enterprise Coach℠ (CEC) and an expert in training, coaching and mentoring across all areas of Agile development. Bob is a popular speaker, having spoken at numerous major conferences, seminars, workshops and user group meetings where his engaging style, holistic view of development and personal anecdotes are always well received by attendees. See his upcoming courses by clicking on Upcoming Courses under Agile For All in the menu at the top of your screen.

Related Articles

Responses

  1. Pedro Oliveira 2009-05-15

    Great article Rob!
    You’ve really captured the essence of what needs to be done to get it right.

    These are challenges we have faced for a long time in the services area of OutSystems and we ended up capturing the INVEST principles in our sizing tool and in the training we provide to all our partners and clients who need to capture requirements and estimate them for projects using the Agile Platform.

    To have a glimpse of how we do it you can take a look at this 3 minutes video http://www.outsystems.com/EvaluationCenter/Demo.aspx?SelectedMovieFolderId=4509.

    All the best,
    Pedro Oliveira

  5. Julen 2014-05-22

    Thanks for the article!

    I have doubt about the ‘Independent’ aspect. For instance, I have user stories that change an attribute of a thing. Let me explain with an example, let’s have this user story: As the boss I want to change the salary of my employees.

    Then I have another user story as follows: As the boss I want to to see a list of my employees to CHANGE THE SALARY OF MY EMPLOYEES”.

    Do you think that is correct to separate users stories that way? Or do you believe that the second user story is part of the first one? And what about the second one has some especial ‘requirements’ such as ordering the list in certain way or adding search.

    All of this makes me confused regarding the ‘independent’ issue…

    1. Richard Lawrence 2014-05-22

      To me, the key value of “independent” is being able to prioritize by value or learning rather than technical dependency.

      The core story of your two examples seems to be one about actually changing the salary. The list seems to be a step towards that goal. But either could be done first, which makes them independent with respect to INVEST.

  7. Vishal 2016-06-03

    Is it really possible to create Independent stories every time? In real situations, I think it is unavoidable that a story will be dependent on the other. For e.g. consider online shopping. The first thing that a customer needs is to be able to search for garments, shoes etc. that he/she wants to buy. Next thing is to display the garments matching the search. And the third thing is to allow users to select, order and pay for the goods. We will have the below stories as an example:

    1. As a user, I should be able to search for shoes based on certain parameters so that I can choose what i want to buy.
    2. As a user, I should be able to view the search results and choose a size, color so that I can decide which product to buy.
    3. As a user, I should be able to place an order and make a payment so that I can purchase the product.

    Now, each of these are stories are dependent on one another in terms of the order. Story 1 should be implemented first followed by Story 2 and then Story 3. In order to create independent stories, if we try to combine these three stories into one, it will fail the Small stories criteria.

    So, is it possible to create independent stories in the truest sense every time?

    1. Richard Lawrence 2016-06-04

      Hi Vishal,

      A couple thoughts:

      1. In the context of INVEST, Independent is about being able to do the stories in any order rather than having to prioritize them by technical dependencies. It’s not about each story being unrelated to the others. Looking at your example stories, suppose processing payments was the highest risk and the PO and dev team wanted to address that risk. They could choose to do story 3 first, setting up known, perhaps hard-coded, product information to fake the earlier part of the workflow that doesn’t yet exist. Then, they could go back to story 1 or 2 and start making the faked steps real.

      2. That said, this particular way of slicing the workflow is the one I recommend against. Working left to right through a workflow defers value and learning and can lead to overbuilding early workflow steps without realizing it. See my story splitting resources and my 80/20 Product Ownership online course for a couple alternative ways to split a workflow.

      –Richard

      1. sam 2016-08-08

        Hi Richard,
        In the above example, are you saying that you would do story #3 first? And that doing stories in the order of 1-3 would defer the value of actually getting the payment processing done?

        Love the blog!

        Thanks

        1. Richard Lawrence 2016-08-08

          Hi Sam,

          As I mentioned, I probably wouldn’t split the workflow like that at all. I’d try to look for a thin slice through the whole workflow to start with.

          But if I did split them that way, and if I wanted to do the stories in a different order such as starting with #3 to address risk or uncertainty around payment process, I could do so with some scaffolding to make the story testable on its own.

          In my response to Vishal, I was highlighting that independence in INVEST is more about being able to do the stories in any order rather than the stories not touching each other in any way.

          Hope that helps,

          Richard

  10. Cornelius Parkin 2017-07-20

    Hey Rob

    Love the article. I have been in a situation where the end-to-end process is so complex, it is impossible to split stories small enough, vertically (end-to-end) so that it can be completed within a single sprint.

    For example. A requirements comes in via PO and the CX team needs to gather user data via various sources whilst the BA further explores the requirement to unpack it so that the team clearly understands it. Once this user data has been collected, the CX person would make recommendations. These recommendations would then determine what to do with the requirement going forward i..e is software development needed, is wireframes and designs needed, should content be written by professional content writers (considering legal and governance) etc.

    This is impossible. I have thought of the following two solutions
    1) Rather run this entire process via Kanban and get the value to the customer asap by identifying and removing bottlenecks in the process
    2) Split (analysis) phase with (build) phase so that all the analysis work is done and understood, and also feasibility determined before aligning it for Build. Analysis would run in Kanban and build would run in Scrum

    Personally, I prefer option 1 because running in various sprints in sequence would be the same as just putting the build portion in the Kanban workflow and would require less admin to break up and manage stories

    What are your thoughts?

    1. Pedro 2018-07-12

      Apologies if I misunderstood you, but it looks like you want to do everything in one go, putting the US directly within the sprint. From my point of view you need as well a good Definition of Ready( the US meets everything required to be included in a Sprint and meet the DoD, for example: US analysed, designed if needed, meet as many INVEST criteria as possible, include Acceptance criteria, etc) , to celebrate some Grooming seasons for working with the US before including them within an Sprint, and it will be good to have some more US statuses to track where you are with a US..

  22. Jose 2020-06-15

    Hi Bob, unless you mean the story should be held in high esteem, perhaps you should consider using Estimate-able (probably not a word) rather than estimable :). Great job!

    1. Bob 2020-06-15

      Actually Jose, if you look for the definition of estimable it means both “to hold in high esteem” or “capable of being estimated”. There is no such word as estimate-able (as you guessed). I decided to use the actual word from the dictionary. It is pretty funny how many people ask about it, so I consider it a conversation starter!

      – Bob –

      1. Jose 2020-06-15

        Hmm… Interesting, and you’re right, a good conversation starter : ) I had actually looked up “estimable” and found that it *doesn’t* mean is ‘capable of being estimated’ from some sources, but then kept looking elsewhere after your post and found, like you said, its alternative definition (‘capable of being estimated’). Thank you!

Report

Harassment or bullying behavior
Contains mature or sensitive content
Contains misleading or false information
Contains abusive or derogatory content
Contains spam, fake content or potential malware

Block Member?

Please confirm you want to block this member.

You will no longer be able to:

  • See blocked member's posts
  • Mention this member in posts
  • Invite this member to groups

Please allow a few minutes for this process to complete.

Report

You have already reported this .