Posts Tagged ‘kanban’

What is a User Story and Why Should I Care?

Marcin Niebudek,

User Story is a most widely used tool in many Agile methods. Sooner or later you will need to work on some of them or you will need to write a few yourself. At first glance the whole idea may look strange. All those agilists tell you about index cards, about putting them on the wall. They organize them into themes, create some strange maps, call some of them epics, etc.

What is a User Story?

Let’s start from the beginning. User story describes part of your requirements or part of whatever you are trying to achieve in general. In software development we got used to some template (but this is just an example):

“As a [user/role] I want a system to have [some functionality] so that I can achieve [some goal].”

For example:

“As a blog author (my role) I want to be able to create categories for my posts (functionality), so that I can organize all the posts that I write into related topics for better reading (the goal / why I need this).”

But also:

“As a doctor (role) I need to have access to a patients health records and history before the patient comes to a hospital for a scheduled visit (process improvement) so that I can prepare a plan and book some procedures and a patient stay shorter (the goal / why I need this)”

The goal

Actually a template is not so important and if you like different one, then just use it. The most important is a goal part. A user story should bring some value, otherwise why would you want to do it? When writing a story always think about presenting it to a person mentioned in a story (doing a demo)? How would you show that the goal was achieved? If answering this question is a problem, then you should probably rethink your story.

Big and small stories

We usually tell that a story should fit into an index card or a post-it note. The point is not to put too much detail in a single story, but it’s not a level of detail that matters. It’s about story complexity and the expected amount of work required to be done. You should be able to complete a story in some reasonable time. If you work iteratively, then your story should fit into iteration. If you measure cycle time, then the best amount of work put in a single story would fit more or less in that time frame.

Does it mean a story cannot be bigger. No, not at all. Sometimes you will have just a raw idea about what needs to be done. Your story may initially be just called “Customer service improvement”. We will call it an epic. This story will get more details over time. You will split it into smaller stories that can actually be implemented.


A story have its own lifecycle. It lands in your backlog as an epic, then it gets some details and becomes a set of stories that we can call ready. This is time to start implementing them. They will now go from to do to completed through some various states (depending on your process). There is one more important step…

A story needs to be accepted. This is when you present the outcomes of your work. You will verify if that story meets the set goal. If not, then it will require some more work (which means it will get rejected), otherwise it’s done.

Themes and story mapping

If you are dealing with a complex product or service then you may have a lot of stories to deal with. Having a large backlog is in my opinion a bad idea in general (and I will write a bout it in a few days) but if you do have such a backlog then it’s a good idea to group stories in themes. Themes will usually evolve from groups of epics.

There is also a very useful practice called story mapping. It’s out of scope of this post and I encourage you to read more about it at Jeff Patton’s blog.

What to do next?

So let’s get back to the main question. Why should you care about stories?

My answer is because they are a powerful tool. I would encourage you to think about user stories even if you do not intend to dive into Agile world. They will give you a good perspective and will help you focus on the right things. If you want to learn more about effectively using stories there is a book I especially like. It’s “User Stories Applied” by Mike Cohn.

Scrum vs. Kanban – How simple is that?

Marcin Niebudek,

This one should be short… When I think about Scrum vs. Kanban question (which is coming back like a boomerang over and over again) I really have just one single distinction in mind – time boxing vs. flow.

If you think about Scrum and Kanban as a process frameworks (and I do so) then you can find more similarities. They both show you how to organize the work flow, give simple tools (backlogs, kanban boards). They focus on team collaboration aspect of the process. They give you simple visual indicators (burndown charts, cumulative flow charts) to quickly spot problems as well as simple metrics to give you the basis for planning (velocity, cycle time).

What is different is that Scrum creates fixed time spans and concentrate some activities around those time boxes boundaries (planning, demos, retrospectives) while Kanban goes for the continuous flow, which usually means that the mentioned earlier activities will blur a bit and change their character to more ad-hoc (instead of Scrum’s meeting oriented) style. So the question you need to answer is actually which type of work flow fits better your organization and the character of your project(s).

Do you prefer cycle with boundaries when you can for example reach your stakeholders every two weeks? Or maybe you need a freedom to make your code base unstable for let’s say 1 week and get it back to deployable state after a sprint without a pressure that this will affect some other features that need to be shipped in the meantime? Scrum might be better here.

On the other hand if you don’t need strict boundaries and you prefer to manage things in ad-hoc meetings. If you can ship features one by one or can work on them independently. If each of those features brings enough value to be shipped alone when it’s ready, then you may find Scrum too limiting and go for Kanban. Maybe you don’t have direct access to your users, your users prefer smaller increments wand want to get updates whenever they are ready. Go Kanban.

As always, you should probably be choosing the best of those two worlds. The important thing to remember is that the framework is not enough. You need to have a high quality engineering practices behind it. And those practices may be the same no matter if you choose Scrum or Kanban.  So don’t spend too much time on it.