- Many teams find that the yellow sticky notes,
or feature cards, are the most difficult to create.
That's because these cards represent something new.
Cards for software bugs are usually easy to describe.
It's also pretty straightforward
to write down a maintenance issue.
So green and red stickies are often much easier to create,
but describing features can be a real challenge.
You have to have a real clear understanding
of what the customer wants.
Then you have to translate that statement
into something that can be delivered.
Many teams try the user story format.
If you've been on an agile team then you're probably
familiar with this way of describing your work.
A user story is a broad value statement.
It's almost like a note to remind you
to have a future conversation.
It's like saying, I should really talk with Shelly
about the data she wants to show on the mobile application.
That's why user stories have an unusual format.
The most common format is, "As a user,
I want some feature so that I can have some value."
So in this case, Shelly might say something like,
"As a mobile application user, I want to see ratings data,
so I can pick a good restaurant."
Although it's common practice to use user stories
on your kanban board, it may not be a good idea.
User stories in themselves,
are not designed to be actionable.
So here the development team will want to get together
with Shelly to talk about how she'd
like to present the ratings data.
Then the development team would go through
the tricky process of tasking out the story
to create a new feature.
That's why you want to be careful
with user stories on your kanban board.
The kanban system represents work items,
they're the actual things that your team needs to do
to deliver a service or product.
User stories are a high-level statement
of what the customer wants to accomplish.
They don't tell you how to do something,
they tell you what needs to be done.
That's why it's usually a much better idea
to keep your kanban card short and task-specific.
Ideally, they should represent a day or so
of time for one person on your team.
Here a good feature card might be something like,
"Display restaurant ratings data
on the restaurant search screen."
It's important to remember that
these cards should be actionable.
A team member should be able to pull the card off the board
and start working on the feature.
They shouldn't have to go back and meet with Shelly
to understand what she's thinking.
Feature cards are also much more likely
to have extra information.
Some teams put emoticons on their cards
to show if they're having a difficult time,
other teams will put red stickers on their cards
if they're waiting for more information,
or if you're having trouble finishing the work.
Some teams even like to put date stamps on their cards
to keep track of how long it took them to finish.
Some teams will also put estimates on their cards.
Always keep in mind that the challenge
with putting too much information on the card
is it gets more difficult for the team to read.
This is especially important when you're just starting out.
So in the beginning, try to keep
your feature cards as simple as possible,
then you can add more complexity as your needs change.