Scrum Stories

While I’m not against having tasks, I am against how scrum handles tasks. Any time something is given a special label to make it sounds better than what it is (like a story instead of a task) I am always skeptical. The reason I’m skeptical is that when this sort of thing happens it’s usually used as a coverup for something else that may not be so great.

I want to be clear about what I’m advocating for and against, so I’ll tell you positive things about tasks in general. I think that viewing your work as a whole from the perspective of the end-user is good, we should always keep the end-users in mind when we make things. My criticism comes in more around the handling of the fancy scrum tasks.

However, one problem with the user stories is that they define a rigid framework. The framework will be fine so long as a user sticks within the bounds of the framework. If they go outside the bounds of the framework it will usually break. This occurs when you have some tasks that require some special cases, and there will always be special cases.

Another problem is that Scrum and Agile try to break down stories too much, which kind of causes the first problem. I’ve often found that Scrum tries to break down user stories to the smallest parts just to break it down. This can sometimes add value, but not if you’re just doing it to do it.

The answer to these issues to really to think about the best implementation of stories and make sure that what you’re describing in your tasks isn’t too rigid a framework. This is really subjective and relies on your understanding of the project at hand, so this is a super loose suggestion and really relies on you, the reader, to interpret this and think about how to apply it. I can’t tell you how to apply this because I don’t work on your team and I don’t know your project.