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:
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!
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™.