Archive for May, 2010

How to mess up your user stories

6
636 days
by in Agile, Scrum

What a mess!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 :)

Open Session: Tai Chi/Zen & Team

0
662 days
by in Agile Coaching

The first OpenSpace session for me today was about Thai Chi and the influence on the team. Christine Neidhardt did some interesting and simple Tai Chi exercises with us and a discussion afterwards what we felt. We started to stand in a circle and focus on ourselves. When we were ready to start we went into the circle and bow to let everybody know that we appreciate that they are also participating. After this introduction we did the first exercise. We took each others hands and started a “La Ola” wave. The challenge was to get a real smooth “La Ola” wave through going round the whole circle. The next and for me more interesting exercise was the following: Clap your hands one after another around the circle and find the rhythm of the team. We got a smooth rhythm with some disturbances in between but after some practice we were able to overcome these and continue with our rhythm. In the last exercise we stood in a line without seeing each other. Christine was starting a movement with her arms which went through the line and back. The first movements were quite easy even if I were the blocker in the first round but it should have been easy because you were able to see the arms of the people in the corner of your eyes but the last movement was really difficult to recognize. You had to try to feel when it’s time to continue the movement without seeing it. Really interesting experience. After the exercises we sat together discussing what we felt during out Tai Chi exercises. You can see the results on the flip chart.

7 things to sabotage an AgileCoachCamp

4
663 days
by in Agile, Agile Coaching

I’m currently participating at the Agile Coach Camp Germany 2010 in Rückersbach near Frankfurt. As some of you already know I’m a lightning talk addict and so I couldn’t resist to do a one this eveAgileCoachCampning. After a bunch of great talks I did my talk on the topic “7 things to sabotage an AgileCoachCamp”. Here is my list:

  1. Don‘t propose any topics for the open space sessions.
  2. Ignore the facilitator
  3. Disturb any sessions by continuously asking questions that are not related to the session topic.
  4. Don‘t participate on any games. You‘re not a child anymore.
  5. Talk on your mobile as loud and often as possible.
  6. Leave, now!
  7. Don’t talk at all.

I didn’t use slides but if you need some, here you are:

Here is the video of the talk. Have fun :-) :


Go to Top