User Stories — Agile way of working
First of all, let’s start with my definition of a user story: A user story, also called PBI (product backlog item) is a group of tasks that combined form a flow/functionality/process for helping an end-user to achieve a goal. As you see for me the benefit/value of a user story is something valuable for an end-user of the app. There shouldn’t be “technical” user stories. All the stories should bring value to the end-user. Now maybe you are thinking about upgrading a framework, well, what benefit will bring to the end-user? Isn’t it a technical user story? Well…in my mind, no, it’s not. An upgrade is usually necessary when the old version is not supported anymore, so the upgrade will usually bring more security and/or speed to the app, so that’s the business value.
I’ll try to write this article by responding to some questions I found in different (Agile) groups, so, let’s start.
Why we should care about splitting the user stories? The answer is simple: we should try to bring value to the end-user as fast as possible. By helping him to achieve a part of his goal at least, we get feedback. Based on the feedback, the PO will be able to prioritize the next stories. Think about the idea of working for 3 months on something and after that the end-user says that he was misunderstood and he wanted something else, or he doesn’t need the functionality at all, because he found other ways to fix his problem, how would you feel?
What is a good user story? To answer this we can talk for days. People understand good and bad in different ways, but what I think is that a good user story is one that is understood by everyone in the team. Understood means that the dev team knows what they need to do and how to test it and of course what’s the benefit for the end-user — why they should actually build that thing. The user story should have a well-written description so that if in 3 sprints the team will look at it, they will still know what is about and it shouldn’t include a technical solution. The technical part should be in the hands of the dev team, the description should be only from the business perspective. The story should describe a business need and value that will be provided after it will be implemented.
What’s the format of a user story? Usually organizations and POs tend to use 2 formats: As a role, I want action so that benefit; or Who, What, Why. In my opinion, the format doesn’t matter as long as everyone understands the value that will provide, the implementation of that thing.
Get Cosmin Vladutu’s stories in your inbox
Join Medium for free to get updates from this writer.
What is INVEST? Invest is an acronym that helps you to get good user stories. It stands for Independent, which means each user story should be able to be implemented by itself and doesn’t depend on something else; Negotiable which means the dev team should be able to negotiate when the story should be implemented if they think something else is more important and be able to ask for more details to get the best way of implementing it; Valuable, each story should bring by itself value for the end-user; Estimable, the team should be able to estimate it — have all the details they need so that they have a clue of how they will implement it (do not forget that if the team use story points for estimating, an SP means a sum of time, uncertainty (risk) and complexity — so, not only time); Small, should be done in less than a sprint; Testable, everyone should be able to test the user story by itself.
Do you always keep the INVEST model in mind? The short answer is: Yes. Even if I have different layers most of the time, I try to work in parallel as much as possible. In a story, of course, the tasks will depend on each other, but you can make UI changes and work on the API endpoint, logic, or database in parallel with others from the team if you created together, a contract between layers. Being a developer, I usually like the idea of vertical slicing, so I like stories that will make me implement a “CRUD like” functionality if the story is too big (meaning create a note for example, in the next story, read the note and so on, but of course, the changes should be done from the UI to the database), or if the implementation is not too large, I like to create the entire functionality in one story and after that have other stories for adding the functionality to different pages of the app, or for optimization, rules etc
Who should be involved in writing the user stories? This is the job of the PO, but in the refinement/grooming sessions, the entire agile team should be involved (PO, SM, BA, Dev team).
Why does the PO need to be the only one that writes the user stories? In theory, he is the first contact with the end-users. He knows their needs and has the best knowledge of the business. Of course, after writing them, the team will help him to refine the stories, but he should be able to come up with all the answers about the business needs (with the help of his BAs). If he doesn’t have an answer, he should go and find it.
What is the acceptance criteria? This is a list of things that should be done for the story to be accepted by the PO, basically the minimum things that the end-user needs to be able to work on your new feature. You shouldn’t include things like, the API should return 500 if something went wrong. This is a technical detail known in the team; the end-user doesn’t care about it. He should be notified in some way (or not, depending on the business case) if something went wrong.
What is the sprint goal in correlation with the user stories? The sprint goal should be something for the entire team. The goal of the team for that sprint. What the team wants to achieve in that sprint. Usually, I prefer to be something that is achieved by implementing multiple user stories, but if only one is very important, you can add only that one.
In conclusion, my opinion is that you should stop saying user stories can be technical (because in the end, even a technical spike is done, for helping the team understand how to implement something that brings a business value), try to keep them small and try to split them into multiple tasks that can be done in parallel. Communication is the key!
