The one where we explore a new way of writing certain user stories — Fernando Cardoce
How many times have you come across horrible user stories, descriptions that make no sense and are a struggle to figure out? Stuff like “As a Database, I want to be updated so that I’m at the latest version”, and yes that’s a real example. This kind of user stories defeats the purpose of the user story and are confusing and useless. Let’s be clear and honest the main purpose of a user story is to clearly communicate something that needs to be done.
When we talk about user stories is important to take into consideration “INVEST”. Every story should cover the keywords that form the acronym invest, which are:
Independent: The solution can be implemented by the team independently of other stories.
Negotiable: The scope of work should have some flex and not be pinned down like a traditional requirements specification. The solution of the story is up for debate by the team.
Valuable: Why? Why are we doing this? W
Estimable: The team should understand the story well enough to be able to estimate the time it would take to complete it
Small: The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint.
Testable: Everyone should understand and agree on how the completion of the story will be verified. There should be a definition of done.
This conditions should be a must in every user story, these conditions can guarantee that a sprint comes out in extraordinary fashion. But these conditions don’t mean that we should write every user story on the same “As a…, I want to.., so that…” format, this format can actually impede that a team have success.
“As an author of the Agile Manifesto
I want that stupid story format to go away
So that people can get to the essence of user stories.”- Ron Jeffries
What we need to focus on is achieving these conditions no matter how we document the story. According to Ardita Karaj’s talk on Agile 2019, as a team, we should go through 3 steps when taking any task, conversation, confirmation and getting the job done.
I would like to focus on the conversation because I feel it concludes into the other two. When we engage in a planning meeting is important to have a conversation over the requirements, and I mean a real conversation, understanding what the other person wants and why. Don’t go into a conversation with a set idea try to construct the solution as a group. For us, in Pernix understanding the client means that we have to understand the context of the client. We are set in Costa Rica but our clients are all over the world. For example, a project I’ve been working on is portal to help kids to get into university, based in Chicago. The college process is completely different in Costa Rica and the US, almost opposites, that’s why understanding the words on a kanban card doesn’t suffice. I have to engage in a conversation with the team and client to understand what we are doing and why, that way I’m able to input my technical knowledge and experience. This discussion with must of the time implies questioning and debating ideas end up resulting in amazing user stories that allow the team to build a well-rounded product.
But how do we “document” this stories, we certainly don’t use the “As a…, I want to.., so that…” since not all user stories can be fit into this placeholder. Let’s say we have a bug of a login button that’s not working. Should we write something like “As a user, I want to click the login button, so that I can log in”? If you ask me that sounds weird and unclear. “As a button, I want to be fixed, so that I work”? Well, that’s just plain awful. What about we think about Friends, remember Friends episodes names? “The One Where Ross And Rachel Take A Break” or “The One Without The Ski Trip”, that’s what we do. to create stories for bugs on our kanbans. The one where when we click the login button we observe nothing happening instead of observing the login process. So this is the option I suggest for bugs for example “The one where and we observe X instead of observing Y (expected observation)”.
What about a motivation base one? “When…, I want to…, so I can…”
An example of this one can be a database task. Instead of “As a database I want some data to be archived periodically so that I don’t fill up” we can have something like “When Database is full, I want to archive some data, So I can collect new data”.
There are several different ways to present user stories, explore them. Remember why we write user stories, communicate with your team and client to make sure everything is as clear as possible so that it coverts the main purpose of the user story. I would love to read about how you write your users stories, please feel free to comment on this post, let’s start a conversation.
