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.
I saw a lot of Scrum meetings out there, that are not more than a skeleton. Everybody is attending but nobody is participating. To improve such situations I collected 11 hints to improve your Scrum Meetings.
1 – Walk the Board
Instead of answering the “three questions”, which leads in most teams to answering only the first two questions, walk the board. This means, use your Sprint Backlog to talk about what is currently in progress and what is planned for today. That way you’re concentrating on the really important things, instead of talking about the past.
More and more agile teams have the problem, that they are not collocated. If you work in a distributed team, you know how difficult it is to stay in contact. It gets even worse, when you have a big time shift between the teams. But in such situations it is even more important to do a team wide retrospective. That’s why I created a checklist for retrospectives in distributed teams. I believe that most of the points also apply to other meetings, like e.g the Sprint Review in Scrum. To facilitate a successful distributed retrospective you need the following:
A Co-Facilitator It is very difficult to facilitate two teams, if one of the teams is located 1000km away. It don’t has to be a experienced coach, just somebody who prepares everything off-site and helps facilitating the retrospective.
There are tons of agile tools out there. Just have a look at this looooooong list on Mike Cohn’s site. But what is the best way to introduce such a tool in your team or company? I collected the following steps for you.
1. Start with no tool at all
A fool with a tool is still a fool. Before you introduce a highly sophisticated agile tool, you need to know how Scrum, XP, Kanban or any other method are working in your own context. If you use a tool right from the start, you won’t follow the process that best fits your situation, but the process the tool dictates. Every agile tool has it’s own understanding, how to implement Scrum or Kanban.
Have you ever been invited to a wedding without food? Have you ever been to a birthday party without a cake? What about a barbecue without the meat? Watching a football match without chips and beer? Even at a funeral they serve some food. Usually when people meet, there is also something to eat (and to drink). People love to socialize around some (great) food.
So why don’t you serve some food, when you have a meeting in your company? I attended an awful big number of boring (and even some interesting) meetings without food. But what I did observe is, that food is one of the secret ingredients for a successful meeting.