agile, scrum, coaching, lean
Agile
5 Signs That Your User Stories Suck
9248 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?
11 Hints to Improve Your Scrum Meetings
6255 days
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.
Daily Scrum
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.
2 – Show what you’re working on
Pictures are often better than words. Show your colleagues what your currently working on. And yes, it is possible to still do this within the 15 minutes time box.
3 – Appreciate the Daily Scrum as a Mini Sprint Planning
The main reason for the Daily Scrum isn’t the reporting. The main reason for the Daily Scrum is to plan your work for the day. The meeting should be used to plan your next steps in towards your overall Sprint goal. Try to change the context of the Daily Scrum and use it as a Mini Sprint Planning meeting.
Sprint Planning
4 – Demand commitment
I know that in the last update of the Scrum Guide the commitment was alleviated, but I think I’m not the only one who thinks this is the wrong direction. At least in Europe I still think that the commitment is an important part of Scrum. That’s why I demand the commitment of every team member e.g. at the end of a Sprint Planning. Write your Sprint goals on a flip chart and let everybody sign it. Put it on the wall of your team room.
5 – Avoid big tasks
I believe every ScrumMaster heard this sentence more than once “This task is not splittable”. Bullshit! I’m convinced that 95% of all tasks can be splitted in smaller ones. Don’t accept big tasks, just because you want to finish the meeting and head to lunch. And this leads us to…
6 – Bring food
The Sprint Planning meeting is the longest meeting in Scrum. Avoid that the blood glucose level is going down and everybody wants to leave as soon as possible. Bring food!
Sprint Review
7 – Rehearse the Sprint Review
Nothing sucks more than an unprepared Sprint Review. Take your time and prepare the Sprint Review properly. If it’s the last day of your Sprint and a feature is still not running, skip it. Concentrate on what is working and prepare a great show. Your stakeholders will love you.
8 – Use the daily Scrum to plan the last steps
The last Daily Scrum should be used to talk about the last steps that have to be taken to reach the Sprint Goal. Nothing is more important that day.
Sprint Retrospective
9 – Define a responsible
At the end of a Sprint Retrospective you normally have a list of (a few) improvements for the next Sprint. But as long as nobody was assigned to the improvements, nothing will happen. I know there are exceptions, but having a responsible team member per improvement helps to keep the team commitment.
10 – Define a DUE Date
The same is true for a due date. You may decide, that all improvements have to be done till the end of the next Sprint, but there are tasks that will take longer. Set a due date for every improvement to help to track it.
11 – Make the results visible
I saw a lot of teams that put the results of their retrospective into a Wiki or an agile tool. The problem with this approach is, that nobody will see them anymore. Out of sight, out of mind. Put the results on a flipchart and hang it in your team room, so that everybody can see them. If a item on this list is done, put a check behind it. Another approach is, to add the tasks of your retrospective to your Sprint Backlog.
I hope this list is helpful. If you have other ideas to improve your Scrum meetings, I’d appreciate a comment. Stay curious!
5 Steps to Introduce an Agile Tool
8269 days
http://www.flickr.com/photos/jrvogt81/4264575563/
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.
2. Use pen and paper
You don’t need a full blown agile collaboration tool to start your agile journey. All you need is a white- or cardboard, some super stickies and pens. That’s it. If you’re working in a collocated team, this is all you need. No distracting electronic tools and no fiddling around how to get this thing working. This is the best way to find out, how to implement your agile frameworks. When you understand, what agile is all about and how to adapt to implement it, that it fits in your context, it is time for step 3.
3. Start with the simplest possible
If you still think you need an agile tool, start with the simplest possible. You can set up a Kanban board in 15 minutes with Google Docs. Or use another simple card based tool like Digaboard, Flow or Linoit. Most of them are free, at least for small teams. The main advantage of those tools is that they don’t follow a certain process, and you can easily adapt them to yours.
4. Choose wisely
You’re still here? So I guess that you still think you need a “real” agile collaboration tool? Than choose wisely! As already mentioned, there are a lot of tools out there. If you followed step 1, you know what your agile process looks like. You need a tool that is easily adaptable to your process. Don’t become a slave of the tools process! If you can’t adapt the tool, skip it. Don’t hurry, when selecting the tool. You’ll probably have to work the next decade with it. That’t why it has to be the right one.
5. Get a training
After you chose a tool, it is important that everybody in your team gets trained. It is important that everybody knows how to use the tool. Nothing is more drowsy than a ScrumMaster fighting with the tool during a Sprint Planning. The tool has to serve you, not the other way around.
Conclusion
IMHO a full blown agile tool only makes sense, if you work with a distributed team. In all other cases, it decreases the productivity instead of increasing it. At least that’s my experience. I’m looking forward to yours, so please leave a comment.
7 Agile Sins
6340 days
http://www.flickr.com/photos/throgers/2891142432/
There are still a lot of people out there who believe, that agile methods are the silver bullet to all their problems. This leads us to the 7 agile sins, that I collected in this post. Let’s have a look at the 7 agile sins (I’m sure you’ll be able to add some more in the comments).
1. Stop learning
You think you know what Scrum is and how it works. That’s why you think you can stop learning new things, am I right? Wrong! Learning is an integral element of agile methods. If you’re open for it, you’ll learn something new every day. The inspect and adapt cycles are not for nothing. If you don’t learn from your experience, every agile implementation will fail.
2. Don’t listen
Or don’t start listening at all. There are some people out there, who think that only their opinion is worthy. It doesn’t count what other people are saying. But as the self-organizing team is the core of every agile implementation, listening is an important trait. Most of the time is more important than anything else. If you don’t listen in a Daily Scrum, it is a waste of time. Of course, the same applies to any other meeting.
3. Stop thinking
Yes, the agile manifest, Scrum, XP, Kanban etc. were created by smart people. But this doesn’t mean that they know everything. At least there is one thing they don’t have a clue about, and this is your current situation. Most of the time it is a good idea to start by the book (at least if you’re new to agile), but don’t stop there. Some things may not fit in your situation, your company or for yourself. Start to think what can be adapted, but still keep the agile core values in mind.
4. Be dogmatic
Unfortunately, there are many dogmatic Scrum teams out there. But being dogmatic has nothing to do with being agile. There is a real life out there, a real project and (what a nasty surprise) real people. When you have a product in production and it crashed, you can’t just sit there and say: “Sorry, we are in a Sprint. Just put it in the Product Backlog, we’ll care for it in the next Sprint”. I bet your customers won’t appreciate such a behavior. Instead, you have to inspect such cases, and adapt your current processes and behavior to be able to handle such requests. Use what fits to your situation and don’t be dogmatic. It’s more important to live the agile values and principles, than to stick what’s written in some book.
5. Ignore the agile values and principles
I saw teams out there behaving like Scrum zombies. They follow all the rules, schedule and attend all of the Scrum meetings, but still don’t get any benefits. Most of the time it’s simply because they ignore the agile values and principles. There are a lot of agile values out there, because most methodologies define their own (Scrum, XP, Agile Manifesto). But in the end there are a lot of analogies. If you don’t know why you are attending a Daily Scrum, and what the value is, it won’t work. Of course, the same applies to all the other things you do in an agile team. Without accepting and living these values and principles, you’ll behave like a zombie and not more.
6. Misuse the agile toolkit
Most of the agile tools and practices are simple to explain but difficult to implement. That’s why there are a lot of great coaches around 
I saw a lot tools misused, but one of my favorites is the Daily Scrum. Often it is used as a reporting tool. But that’s not the intent of the Daily Scrum. IMHO it’s a smaller version of the Sprint Planning (see “Don’t be a Scrum Zombie”). What I also saw a few month ago, was the misuse of the sprint backlog in a team. The former project manager went around, to track what each of the team members was doing. And even worse, he confronted some of them with their performance, because they finished fewer tasks than the other team members. Primarily the sprint backlog is a tool for the team, and not for the management or the PO. Use every agile tool like it was intended and don’t misuse them.
7. Ignore the transparency
This sin I saw a lot of times, and it’s one of the most evil. Contrary to other opinions, Scrum and other agile toolkits won’t solve your problems. They will make them visible. It’s up to you and your team to handle this transparency and act accordingly. I know there are people out there, who love to close their eyes and ignore what’s happening around them (see also my article about watermelon reporting). If they know about a problem, they have to do something about it and are not able to blame somebody else. But ignoring the problems won’t help you. You have to cope with the truth and act accordingly. In the past, you were able to set a deadline in your ivory tower, but know an agile team is able to question such a deadline, based on their velocity and the size of the backlog. You can ignore that you won’t make it, or you try to find a solution for it. In short, if you want to be agile, you have to embrace transparency.
I know there are even more sins out there, and I’m looking forward to yours. Please leave a comment, thanks.
Kaboom – Blow up your watermelon
2397 days
This is the video and the corresponding slides of my talk “Kaboom – Blow up your watermelon” at the ACE! conference in Krakow. You can read a retrospection of the conference here. Enjoy!
And here are the slides:
Recent comments