INVEST in User Stories
This is the second article of topic user stories and I will explain using invest principles while writing user stories. If you want to understand how and why user stories are born please proceed here to read the first article.
If you are researching about invest principles of user stories, you have probably already understood that software requirements is a communication problem and why to invest in user stories. Lets jump to the details of creating good user stories.
In this article we will talk about INVEST ,an acronym for six attributes firstly suggested by Bill Wake who is the author of Extreme Programming Explored and Refactoring Workbook. We will give the examples from the book User Stories Applied by Mike Cohn. Invest stands for 6 attributes;
- Independent
- Negotiable
- Valuable to users or customers
- Estimatable / Estimable
- Small
- Testable
Independent
Stories should be as independent as possible and care should be taken to avoid introducing dependencies between stories. Real problem of dependent stories is the prioritization & planning problem. When dependencies come into play, it may not be possible to implement a valuable story without implementing other much less valuable stories. In other words stories can be worked in any order. Let’s think about these 3 stories;
- As customer,
I want to pay with Visa card,
So that I can complete my order. - As customer,
I want to pay with American Express card,
So that I can complete my order. - As customer,
I want to pay with MasterCard,
So that I can complete my order.
Stories above listed are so similar to each other. Only difference is the card type that customer wants to pay. To play these stories you need to take estimations and with highly dependent stories such as these, developers don’t know what estimate to give each story. Because all 3 of them depend on the first story which will create the infrastructure with a bigger estimation and the rest two of them will have smaller estimations. So which one should we play first?
There are two ways around it:
A- Combine the dependencies into a larger but independent story.
Larger Story
— As customer,
— I want to pay with credit card,
— So that I can complete my order.
In this method you put all the credit cards and their estimations in one story. This is acceptable if they are still okay for the team’s standart. But also there is a risk to have a too big story. What do we do in this case?
b- Find a different way to split the stories.
Story 1
— As customer,
— I want to pay with one type of credit card,
— So that I can complete my order.Story 2
— As customer,
— I want to pay with two additional type of credit card,
— So that I can complete my order.
In this example you did not mention anything about it but you have delivered a single type of credit card payment with the infrastructure. Also you can simply put two estimations on each dependent story, one estimate if the story is done before the other story, a lower estimate if it is done after. That also works.
Negotiable
One of the main goals of user stories is to get people talking rather than writing.
As I mentioned many times, user stories are there for solving the communication problem. Whole point of this solution comes from the attribute of negotiable.
Stories are not written contracts. It is not the requirements that the developer must implement. They are very short descriptions of a functionality, which are to be negotiated in a conversation between the customer and the development team.
How can we write negotiable stories? This requires a lot of reading and practicing. But there is an example that makes us understand what is negotiable and what is not.
Example 1 (Not Negotiable)
As a user,
I want to authenticated with username and password,
So that I can start using the application.
In example 1, we have given the details of the story in the I want section. What is the problem of giving too much detail? This user story directly leads people to think about an authentication system with a username and password. But I could also authenticate using voice such as Siri, or faceId or with my Facebook account or with email.
So in example 1, we give the details of the authentication system basically UI, and that killed the discussion opportunity for how to do that authentication.
Example 2 (Negotiable)
As a user,
I want to authenticated,
So that I can start using the application.
Quick Learning: The more you describe theUI, it makes the user story less negotiable.
More Information: While writing stories you need to think from the eyes of customer in all environments. So if you write a user story with the verbs “Click, Tap, Hover, Swipe”, you describe some information about the environment, which makes story again non-negotiable. Because
Click, Hover happens only on Desktop (Computers).
Tap, Swipe happens only on Mobile/Tablet Devices.
If you are not creating a specific story for environment, Instead of click & tap you should use an applicable verb such as “Select”, so that negotiation opportunity still remains.
Valuable to users or customers
Best approach to understand valuable is to think about the deployment of the user story whenever it is completed. Let’s assume that you have the infrastructure of CI/CD (We will talk about these in the upcoming articles.) and you can deploy each story directly after the development. To understand a user story is valuable or not you need to ask a simple question:
- Do customers benefit something from that user story?
If your answer is yes, this story is valuable.
A common mistake is to have stories that are only valued by developers. For example, to describe the need for system stability and performance enhancement you should avoid stories like these:
1- All connections to the database are through a connection pool
2- Turn all API requests from sync approach to async approach.
As written, these stories are focused on the technology and the advantages to the programmers. It is very possible that the ideas behind these stories are good ones but they should instead be written so that the benefits to the customers or the user are apparent. This will allow the customer to intelligently prioritize these stories into the development schedule. Better variations of these stories could be the following:
As a user,
I want to interact with the system in a rush hour with 50 more users,
So that even with high traffic I can use the system.As a user,
I want to do a transaction under 3 seconds
So that I can use the application with high performance
Quick Learning: All stories can be described in customer’s eyes, even the technical stories have some value for customers.
More Information from the User Stories Applied: The best way to ensure that each story is valuable to the customer or users is to have the customer write the stories. Customers are often uncomfortable with this initially—probably because developers have trained them to think of everything they write as something that can be held against them later. (“Well, the requirements document didn’t say that...”) Most customers begin writing stories themselves once they become comfortable with the concept that story cards are reminders to talk later rather than formal commitments or descriptions of specific functionality.
Estimatable / Estimable
In the previous article we mentioned that user stories can be used for project management. The attribute Estimable gives us the ability of managing the project and creating the timelines. To create them a product owner or a project manager needs to know estimations of each story. So yes, we need to give an estimation to each story.
But sometimes developers cannot give an estimation for a story. Three root cause;
- Lack of domain knowledge
Generally happens when new developers join the team, in this case it is better to make developer discuss with the customer team so that developer can understand what customer really wants. - Lack of technical knowledge
Usually this happens, when the developers need to implement a technology which they are not familiar with. In this scenarios, giving a spike card can be the best approach. With spike cards, devs can research about the technology within a timebox. So that they can improve the technical knowledge. - Story is too big
No need for explanation. Just split the story into smaller pieces.
To sum up, a story needs to be estimable and until that state we need to take some actions as mentioned above.
Small
User stories need to be small, because if you create a large or xlarge story, then you will probably face problems on:
— Estimation → Devs cannot estimate the stories.
— Delivery → Let’s assume we agreed on that large stories can be completed in 2 iterations and a story “L” estimated as large. Probably while developing this large story, devs will face some unexpected errors and they will try to fix these unexpected errors. While fixing them, they can see some unplanned communication with any other system and they can put some additional scope into the story. Which means it can delay the delivery. Large estimated stories are usually the danger signals. The devs gave it large due to unknown issues.
In addition to that, a long or delayed development process is also breaking the feedback cycle (We will talk about these in the upcoming articles.) which carries crucial importance on the delivery process.
We need to split the stories into smaller stories. This is whole another article we will write later. But you can do some search on the internet, there are lots of them.
We mentioned being “small” many times. What does being small mean? Usually small means the user stories that can be completed within an iteration. Iteration length can be changed from squad to squad, so small is very relative term and there is no possible way to display as one certain way.
Quick Learning: Large stories are the warning signals.
More Information: There can be stories which are smaller than “small”. In these cases we can combine some tiny stories into larger story as large as “small” story. The combined story is given a name and is then scheduled and worked on just like any other story.
Testable
Every story needs to be testable in order to be “done.” In fact, we 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 customer
I want to find a software easy to use,
So that I can use the software with joy.
This is not a testable user story. It is not certain how to test it, also it is not possible to automate this process on automated tests.
Quick Learning: Stories need to be testable.
I hope you liked it. Special thanks to Melis Keser & Tuğrul Çavuş for helping.
If you have any comments please ask it! For now this is the end of the second article about “User Stories”. See ya!
This is the end of second article. Next articles will explain
- How to use user stories for project management?
- How to use user stories for Continuous Integration?
You can reach the first article from here:
