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?
Thanks for this. I’ve just come into a scrum team from ‚cold‘ and was struggling with the granularity of the stories I’m seeing and their purpose as they ate very different to my experience. This has formalised my objections rather nicely and I’ll be discretely drawing attention to it tomorrow.
You’re welcome, I’m glad when I can help.
I run a highly effective number of teams that use scrum. Their code is quality, their customers happy, we are recognised in our industry as leaders in this area and we help others to get started. My teams do everything you are telling them not to do in this article. Can you explain that to me?
No, I can’t. I observed these strange „user stories“ only with inexperienced teams. I can’t imagine that your’re able to produce great software based on such „user stories“.
Your post is great! I’ve translated it into french :
5 signes indiquant que vos user stories ne sont pas terribles
Thanks! Glad you liked it 🙂
I think one reason for small User Stories is that you find them in almost every scrum book. Examples like: „the user can delete a book from his wishlist“ are very common. This is something that is done within a day or less with most development enviroments and setting.
Another reason for small User Stories is something I call „Story Erosion“ (is this english?) You start with a story like „The User can use a wishlist to remind him of books he wants to buy“. At the end of the Sprint there is a chance that something like this happens: „we did all the acceptance criterias, but we found out that it would be cool to sort this list“. So there is a new (and very presumably small) User Story: The user can sort his wishlist.
This dynamik is something you have to work with as PO. In my experience it is not useful to forbid large or to small User Stories. It is a natural process. Which leads me to the next story… tooling 😉
I don’t think that small user stories should be forbidden. For me it is just one sign that you should have a closer look. If you write a small user story only to tell the developer to finish the documentation, it is useless. Don’t use a user story as a wrapper for single tasks.
I like the thinking. We should be eliminating waste and concentrate on improving ourselves at every turn. Yes we’re in the delivery game but surely that should not be our only focus.
Great points on creating effective user stories. After struggling with effective methods for creating tasks for user stories, I did some digging and wrote a brief article about the benefits of creating measurable tasks for user stories that I call Functional Smart Tasks. Others may find it valuable when exploring user stories and managing development.
It’d save a lot of confusion if you gave an example or two of the bad practice, and then an example of the more progressive way. You kinda did it in point 5 and that was the clearest point you made in my opinion, and yes personas (literaltext or fully-fledged) would help and be the better user-centred practice.
E.G. „As a busymobileuserondroppylossyconnection I want several news items to download automatically for offline reading so that I’m entertained all the time.“
busymobileuserondroppylossyconnection being a literal persona, and a fully-fledged persona would
As Bert (and then hopefully a link to Bert’s full persona, or a persona highlights pic of Bert on the Kanban wall)
I have also found use in having user-centred stories like:
„As a TechArchitect I want an abstracted data-layer (DAL) so that I can use multiple data sources and devs don’t hardcode the model“ especially when in sprint 0 and would otherwise be ‚burning‘ nothing. You could bury all that work into a development black hole, but i found calling it out at a high-level meant other stakeholders were cool de la with our progress from the get-go.
I agree with this post, especially point 1.
I have inherited a small backlog of what are essentially legacy design enhancements. In other words, ‚fixing‘ things wrong around design and content that were previously delivered some time back.
Following a content and design audit, we have an output of a list of things that ’need‘ to change.
For example. We have since updated design patterns and some of the items we need to address is just that. Given the functionality exists in all areas and these items are just addressing the updates/changes – are we ok to stray away from ‚user story‘ format? And if so, what are the minimum content expectations within each ticket do you think?
Any input would be much appreciated.