- So you've seen how you can create different types
of kanban cards.
You can use different colors for each
to keep track of the type of work on the board.
You've also seen how teams can put different types
of extra information on the cards.
The most common type of information is high-level estimates.
High-level estimation is a common practice
for most agile teams.
These teams usually use story points.
Story points often use something like the Fibonacci sequence
to come up with an estimate to deliver the card.
So you might have cards that'll have something
like one, two, or eight points.
These numbers don't represent hours or days.
Instead, they show a level of effort.
A two will be roughly twice as difficult as a one.
It's very common to use a group decision making process
to come up with these team estimates.
But remember that kanban teams are different
from typical agile teams.
The emphasis on kanban is to pull a predictable amount
of work through the board.
Your team should put a lot more effort
into cadence and maximizing the flow.
Think of it this way.
Kanban is a system to improve the way you work.
You can use it to improve your processes
and deliver at a predictable pace.
On the flip side,
agile is primarily a product delivery system.
At the end of the day,
it's all about delivering a software product.
That's why kanban can be used
for many different types of work.
You can use it for your help desk, operations,
human resources, and even manufacturing.
So you should be very careful about using story points
or any other planning and estimating practices with kanban.
You might be spending more time planning than working.
Let's imagine a help desk team
that's using kanban for their ticket system.
They'll use three cards
to show different classes of service.
They'll use red for the most serious, then yellow and green.
Now let's say that a ticket came into the system
that said that the instant messaging system was down.
The first team member to see the ticket creates a red card
and puts it up on the board.
At this point, you wouldn't want to get the team together
for a long planning session.
It wouldn't really matter how long the work takes
because someone should start immediately.
Even if there were several red cards on the board,
the kanban team wouldn't want to go
through the time-consuming process
of coming up with high-level estimates.
Remember the value to the customer is fixing the tickets
that represent the most severe problems.
In a sense, an estimate of how long it will take
is not relevant to your customer.
From their perspective,
it's much more satisfying to see someone working
than get an estimate for how long it will take to finish.
On the flip side, it might make sense
to have high-level estimates
if you're using kanban to deliver a product.
In that scenario, you'll be coordinating with other teams,
so the customer wants a sense
of when the product will be finished.
That's why you want to take extra special care
when you're thinking about whether to use estimates
with your kanban team.
Don't just assume that since kanban is used with agile teams
that it makes sense to adopt all of agile practices.
Think about whether or not your customer
values planning and estimating.
One quick way to think about it
is whether it's more important
to do the work than plan the work,
then you probably just focus on optimizing your flow.
If your customer needs
to release a product at a certain time,
then you might want to create some high-level estimates.