As you probably noticed title is a Scrum user story template. It allows you to identify three very important elements:

  • [mark]user[/mark] whose business need will be satisfied
  • [mark]functionality[/mark] which will be developed
  • [mark]business value[/mark] which will be provided.

It seems that writing uses stories is very easy but it is not. You can make a mistake easily. Please try to remind yourself how often you had seen the following stories:

[quote align=”left”]As a user…

As a product owner…[/quote]

Many of us can say that those are quite normal user stories. But please try to look at them from other perspective. Please try to focus on those three mentioned issues. In such user stories you are losing very important information about user who will be working with our application. I believe that UI will be designed in different way for somebody who is keen on with technology and for somebody who is not so good with working with computer (e. g. your accountant).

The second issue – functionality – in most cases is written correctly. But the third one is sometimes omitted. Moreover in stories people forget about acceptance criteria. Please try to think about such situation. Probably in most cases you should be able to implement requested feature only with description of functionality. But do you think it will be the best solution that you could provide to the users?

I believe not. In my opinion only when you have all of those information you will be able to understand the whole context of situation and finally you will be able to provide solution that will provide maximum business value for specific user. Moreover acceptance criteria will allow you to check in easy way if your solution is good enough from users’ perspective.

Let’s think about solution for this issue. Lately am trying to measure quality of stories. To do that I am using INVEST model that was developed by Billa Wake. With this model you can say that story is good only when it has the following characteristics:

  • [mark]Independent[/mark] – stories should be independent and you should be able to implement each story regardless other ones’. This characteristic should allow Product Owner to change order of stories in backlog. Then at top of backlog there will be always stories that will provide biggest business value. Each time when story has dependencies it can force to change order of items in backlog. It can lead to situation that development team will need to provide solution for story with smaller business value before implementing proper user story. Such situation is not good for customer.
  • [mark]Negotiable[/mark] – you should remember that Scrum team is composed of three roles: Product Owner, Scrum Master and Development Team. People involved in this process should always cooperate. Situation when during planning Product Owner is presenting user stories and Development Team is only estimating them is not correct way of working in Scrum. That is why we should remember about this characteristic. Each story can be changed or even discarded on almost each stage of process. This negotiation should make story better and provide correct description that will not focus on details implementation but on the main gist of the matter.
  • [mark]Valuable[/mark] – each story should generate value for customer. Sometimes it is hard to find business values in some user stories. Sometimes even you can lead to situation that you will be involved only in stories that are not generating business value. It happens especially when you are starting a new project. A lot of development teams are focusing on creation of database schema, layers design, architecture implementations, …. Finally after month, quarter or even a year they are staring implementation of UI. First features that will bring value to customer. And during this architecture phase customer can only trust development team that he will finally get product that he needs. But you can do that in other way. Please try to think about layers in vertical way. Then instead of development whole layers from bottom to top try to develop smaller parts of each layer during each sprint – a bit of UI, a bit of middle layers and a bit of database. Then after finishing each story customer will be able to test it, make decision about future requirements and finally he will be able to deliver it to production and start using it.
    Sometimes you need only change description a bit to show business value. Last time I wrote story that we could defined from technical perspective in the following way: please add new field isEnabled to OrderCategories table. I believe that every developer will know what he should do in such case. But you can also think about this requirement from the following perspective: accounting would like to be able to hide order categories that are no longer needed in application. In this case you can see business value clearly.
  • [mark]Estimable[/mark] – you should be able to estimate each story. This information together with business value should allow Product Owner to define order of items in product backlog. Please note that not always stories with biggest business value will be done first. Sometimes implementation of those stories take too long and Product Owner will decide that Scrum Team should focus on stories with lower business value but also with lower estimate. Then team will be able to provide business value faster to customer.
    Each time when team will not be able to estimate story you should think about dividing this story to smaller ones’. And then try to estimate those new stories separately. Of course even then sometimes you will find story that team will not be able to estimate. In such situation you should give team some time for making investigation related to this story and after then team should try to estimate it again.
  • [mark]Small[/mark] – in most cases team working with smaller stories is able to estimate and plan it easily. It is also easier to control realisation of smaller stories and estimates are more accurate.
    There is only a problem with definition of small story. Of course it depends on a project. For me a small story is such story that can be delivered by one person in one week. In most cases when this time is longer I am trying to divide story to smaller ones’.
  • [mark]Testable[/mark] – each story should provide information how this new feature should be tested. This information should be provided before start of development. Only then you can be sure that requirements are defined correctly. Each time when this information is missing should be a kind of warning for you. Probably Product Owner is not sure what he would like to get for a team.

In my case each time before starting work with user stories I am putting list of those characteristics on my desk and I am trying to write stories that are fulfilling all of them. Sometimes it is very hard. For me the hardest one is Independent. In case of some stories it is impossible to write stories without dependencies to other ones’. And finally I am asking other person for a review. After a review I can be sure that stories I wrote are clear and understandable for others.