agile, scrum, coaching, lean
Posts tagged user stories
5 Signs That Your User Stories Suck
9143 days
http://www.flickr.com/photos/arlette/3260468/
About one a half years ago, I wrote an article about how to mess up your user stories. In the meantime I saw other “User Stories” that gave me creeps. That’s why I decided to write this article. So here is my new list of signs, that your user stories suck…
1- Your user Stories Are Only a Wrapper
If your user stories only consist of one task, this is a sign that you just using them as a wrapper. I don’t know why, but it seems that some people believe, that they have to use the user story format for everything. A user story is “a promise for a conversation”. If there is nothing to discuss and it is a simple task, than write it down like this. Don’t wrap a pseudo user story around it. In most cases this is also a sign that your user stories are too small.
2 – Your user stories can be done in less than a day
If you have 40+ user stories on your Sprint Backlog, it gets really hard to get a commitment from your team. Some people might say now: “Wait, isn’t it great if they were able to create such small stories?”. Yes, it is great, but not if all of these stories are tasks. In such cases, these stories belong to a bigger story and don’t make sense on their own. Check if your stories are meant to add new functionality, if not something is wrong.
3 – Your user Story Doesn’t Describe a Feature
This is somewhat related to 1 and 2, because in most cases these signs come in together. If your stories are describing tasks for the developer, instead of describing a new functionality, something went wrong. I saw POs writing user stories that described thing like “Write document X” or “Create acceptance test Y”. In those cases I’m asking for the DoD of the team, because those things clearly belong there. And if you don’t want to add them to the DoD, create a task but don’t rape the user story format.
4 – You Use It For Everything
It’s great that you decided to use user stories to create your backlog. But you know what: You can use any format that you like. There is no rule in Scrum that you have to use user stories. You’re not forced to use this format for everything that is in your backlog. In a lot of cases it just don’t make sense, e.g. when you want to add non-functional requirements. Instead add those non-functional requirements to the acceptance criteria of your user stories. If they apply to more than one, create an epic and add it there. But please, don’t use the user story format for everything that is in your backklog.
5 – You Lost Your User
Did you write stories like: “As a project manager…”, “As a product manager….”, “As a developer…” or “As a test technician…”? Than you have lost the real user of your software. It won’t be the project manager or product manager who will use your software. Start over and ask yourself who will use it and write your user stories with their view in your mind. Another possibilty would be to create personas. But always have your user in the focus.
I’m looking forward to your comments. What signs did you observe?
How to mess up your user stories
6619 days
User Stories are more or less the standard format for managing your product backlog in agile projects. So this is my trigger to let you know how to completely mess them up 
I collected a short list of my favorites, let’s start.
Missing Roles
Don’t define any roles! It is much more fun to write a user story from the view of a generic user. Don’t waste your time to define all these useless roles. If I write a story about the possibility to delete any user from the database it should be clear for anyone that I was talking about some kind of admin.
Loooong and detailed descriptions
Try to write your user story description as long and as detailed as possible. Put all your details and acceptance criteria into the description. A perfect user story description should look like this:
As user I want to edit the profiles of the user by switching to the admin dashboard and viewing the list of users. With the right-mouse click on one of the user entries a context menu opens were I'm able to select "Edit User Profile" by clicking the left mouse button. A dialog opens [.... blah blah ....] because it may happen that the data of a user changes.
With these kind of user story description there is no need to write any acceptance criteria or start long discussions. You only have to read the description and everything is right there.
Write detailed right from the start
Forget about epics or “big” user stories. Forget about well formed product backlogs were everything on the top is detailed but the backlog items in the middle or at the bottom are more or less unspecified. Write your user stories as detailed as possible right from the beginning. Hey, you’re the product owner you know how your product will look like in the end you don’t have to wait.
Promises are there to be broken
“A promise for conversation”? You need to discuss your great ideas with the dumb developer folks? Then you have to work harder! Take your time to write every single story so that there is no need to discuss anything. Ignore the fancy ideas from you customer, ignore the disturbing ideas from your development team. Again: You’re the product owner, you know you to built great products. If you write a user story it is carved in stone!
Ignore the INVEST model
You know the the INVEST model? Whos idea was it to define such useless features for user stories?
- Independent: It is not possible to write independent user stories, believe me. Don’t waste your time trying to split or combine user stories to get independent ones.
- Negotiable: Ehm no. Your user stories are not negotiable at all. You’re the master!
- Valuable: If the user story produces some work for your development team it should be valuable enough!
- Estimable: Estimable? Why? You already estimated the whole product backlog. There is no need for anyone else to estimate YOUR user stories.
- Small; A user story is small enough if it can be printed on 10 DIN-A4 pages!
- Testable: Documentation over running software. Do I need to say more?
That’s it for now. If you follow the above rules you’re on the right way to mess up the whole user story fuss. Did I forget something? Don’t hesitate to write a comment 
Recent comments