How to mess up your user stories


Minuten Lesezeit

Sei dabei und sichere Dir bis zum 31.05.2024 Dein Early-Bird Ticket!

Mai 27, 2010

Hol Dir hier das kostenlose Probekapitel meines Buchs

Klicke einfach auf den folgenden Link und melde Dich an.

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 🙂

About the author 

Marc Löffler

Marc Löffler ist Keynote-Speaker, Autor und Mentor für passionierte Scrum Master. Er befasst sich schon seit 2005 leidenschaftlich mit agilen Methoden, wie z.B. Scrum, Kanban oder eXtreme Programming. Bevor er mit dem Thema Agilität in Berührung gekommen war, hat er als zertifizierter Projektmanager (IPMA) bei Firmen wie Volkswagen, Siemens und EADS erfolgreich multinationale Projekte geleitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und genau die Form von Agilität zu finden, die zum jeweiligen Unternehmen passt. Dabei nutzt er sein PASSION Modell, um die jeweilige Situation zu analysieren und sinnvolle nächste Schritte hin zur passionierten, agilen Organisation zu definieren. Er liebt es, neue Einsichten zu generieren, und unterstützt Unternehmen dabei, Probleme aus kreativen, neuen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley. Im Februar 2022 folgte dann das Buch "Die Scrum Master Journey" beim BusinessVillage Verlag.

Leave a Reply

Your email address will not be published. Required fields are marked

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

  1. * Don’t have a Product Owner: the Scrum Master is able to easily be the Product Owner. And as the Scrum Master should be someone of the development team, the team has full responsibility and freedom!
    * Don’t write User Stories at all: as the team has full responsibility and freedom to define the product, there’s no need to have any User Stories or any other kind of specifications.

    Have fun 🙂
    Marc Bless

  2. *The scrum master as product owner? Just a manager should be enough. She can write the user stories….
    *Don’t let anybody know what is on the productbacklog. It will save you al lot of questions!
    *If you make a productbacklog make sure is has at least enough stories for the next 2 years. You don’t want the change priorities all the time!

  3. Pingback: (Agile) Testing
  4. User Stories are documentation. Documentation can be easily out-sourced to an external junior consultant who is new to the industry …

  5. Generally I don’t read article on blogs, however I wish to
    say that this write-up very pressured me to take a look at and
    do it! Your writing style has been surprised me.
    Thanks, very nice post.

  6. I like the idea of your article and the tone, although since I have a hard time understanding things unless they’re literal, I get confused with the assertions you’re making. The context you create it is „how to mess this up“, which requires that you make assertions with critical or neutral comments about each action.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir die kostenlose Anleitung für
Deine persönliche