What is a User Story and its Importance in Kanban

Many teams are using Kanban so they can visualize their tasks and manage their workflow better. They plan their work through Kanban cards on a board. These Kanban cards indicate the details of the task and the expectations that must be met to complete it. While there is no required and fit-for-all template when it comes to formatting your Kanban cards and what to put in them, more teams are using user stories in their Kanban implementation. Let’s explore what a user story is and why it works for Kanban.

What is a User Story?

In traditional software development, we’re used to creating lengthy requirements documents. We put so much effort into writing all the technical details of each field on the screen. The longer the description, the better.

Or so we believed.

Traditional requirements documents are usually written in a technical sense – from the point of view of building the application. And when this happens, there is a high possibility of losing sight of what users need. 

Enter user stories.

These started in eXtreme programming (XP). Ron Jeffries, one of the founders of XP, defines it as “a piece of system functionality, understood by the Customer or Product Owner, representing an increment of business value, to be implemented by the team.” Compared to a traditional requirements document, a user story isn’t a requirements document. It represents what it is the team needs to deliver. Because of its straightforward approach to describing product increments through the user’s point of view, teams use user stories to spur discussion. 

“So this is what the users need to have. How do we provide this to them?”

This is a common starting point of the conversation that takes place when teams discuss user stories. And it is through these conversations that details are fleshed out. The team can then document the conditions by which they can consider that a user story has been completely delivered.

Why are User Stories Important in Kanban?

There are no stringent rules when it comes to putting details on your Kanban cards. But using user stories to communicate what your teams need to do enables you to deliver high levels of customer value. 

Here are some reasons why you should use it in your Kanban implementation.

Precision Without Getting Too Much into the Nitty Gritty

A user story initiates verbal conversation. Fleshing out the details through conversation makes details more precise. It’s also easier to establish a common understanding through verbal conversations. 

Requirements documents can be imprecise depending on the interpretation of the one reading them. By using user stories to plan your product development, you can minimize rework and deliver the features that your customers need.

Planning and Prioritization is Easier

It puts customers’ needs in the spotlight. When you know what your customers want, it’s easier for you to prioritize which features need to be developed first. When you use the traditional requirements document to plan your project, the details make it harder to sift through what matters for your customers.

Boost Collaboration

Lengthy requirements documents can hinder collaboration. More time is spent reviewing them and trying to figure out what they mean. With user stories, teams are forced to have a conversation and come up with a common understanding. Focused conversations using this coupled with the highly visual nature of Kanban will help your teams ensure the highest levels of value delivery are obtained.

Creating Kanban User Stories

User stories are written in this format:

As a [type of user],

I want [a goal or objective],

so that [customer benefit or value].

Let’s take for example a talent recruitment application. A lead recruiter needs to get a report that shows how long positions get filled. This will help the recruiter manage their hiring needs and allocate a budget for more recruiters if necessary. When follow the format, we can say:

As a Lead Recruiter,

I want to generate reports on how long it takes my teams to fill positions,

so that I can plan our team’s staffing needs.

You can then put this on a Kanban card. If you’re using an online Kanban board, you can easily fill the card with the details. Here’s an example of how a Kanban card user story can look like in Kanban Zone.

In the example above, you will also see the acceptance criteria for this user story sample. Acceptance criteria are a list of conditions that need to be met to complete a user story. This is the result of the conversations you and your team will have as you flesh out the details on that card. 

Questions like the following will pop up in your conversations and you can take note of what you and your team agreed. 

• What details need to be in the report?
• What format should the report be in?
• Can the user filter the report? What are the filter options?

The agreements become your acceptance criteria. And as you develop and have to conduct many types of testing of your features, go back to your user story and ask yourselves if you’ve satisfied your acceptance criteria or not. Only when you fulfill them will you consider the task done.

Create a Clear User Story

Your user stories should be clear and concise. One test you can do to assess their clarity is when your teams can estimate the work needed for it. Clarity doesn’t depend on how much detail you put into each story. It depends on the common understanding you and your teams arrive at so that you’re all on the same page on what it means to achieve a goal. 

While Kanban helps you manage your software development process, user stories help ensure you work towards doing the right things for your customers. It will help your team get to the bottom of what your customers value the most. Start creating user stories and start building products your customers will love.