
Ask HN: How does your team run the kanban backlog/board? - ryandetzel
I&#x27;m looking for clear examples of how backlogs and boards are run with a mixed &quot;full-stack&quot; developers.<p>We&#x27;re trying a new process where the backlog contains every ticket from every project we&#x27;re working on plus bugs from all other services we ownr and the dev just pulls the top ticket regardless. In practice this could mean in a single day I could pull a frontend task in project 1, backend task in project 2 and a bug in a completely different service. To me, this constant context switching gives me nightmares but everyone else says this is normally how kanban is run but I can&#x27;t find any real world examples of such a process. How does your team handle kanban and do you mix unrelated projects in a single backlog&#x2F;board?
======
mharroun
Our product/dev team is ~18 but how I like to do these things:

\- "Projects" are set as epics / clusters of tickets

\- Ordering of the backlog/board follows as such:

\-- Critical bugs

\-- Critical "One off" Tasks

\-- Sets of Project tickets by priority.

\-- Uncritical issues if time allows (moves up in urgency as it sits)

Ideally the following happens for us:

\- A group of 2-4 devs work on each project batch of tickets

\- If a bug/task can be done by the person who "owns" that system they should
do it, but this should never delay critical work.

We have a 30 min weekly meeting to review the status of completed/in-progress
work as well as discuss newly added bugs and one-off tasks. Some times this is
as fast as 10-15min. This is where we poll to feel if we will hit the
deadlines of the product/engineering roadmap and compensate if needed.

Major projects/epics follow a project kick off meeting and then a technical
spec/review phase before tickets are then put into an epic to be executed.

------
NotPaidToPost
This is odd.

The backlog is supposed to be a product backlog, i.e. in general a project
backlog.

The board helps you see at a glance the project's status.

So to me it seems that merging everything into a single boards is confusing at
best.

I would have a board per project. This does not prevent devs from switching
between projects on a per ticket basis but keeps things well organised and
managed.

~~~
adrianmsmith
But I see the point of the author's idea of mixing all the tasks together: To
be able to answer the question "what's the most important thing I should be
working on now (across all projects)?".

~~~
NotPaidToPost
It's not necessary to mix everything on a single board just to answer that
question In fact, mixing everything may not even make answering that question
easier.

Relative priorities of projects may change. If I tell my devs "project X has
priority at the moment" they just need to focus on project X's board.

In any case, if you colour-code you can see at a glance what task looks most
critical by looking across a few separate boards.

~~~
adrianmsmith
In my experience (but maybe it's just me, maybe other people manage their
projects differently), the type of task plays a greater role in its
prioritization than the project. For example, we always fix bugs first, even
if that pushes back delivery of new features. Stability issues are even more
important than bugs. And security issues even more important than stability
issues.

Yes you could have multiple boards, each with its own backlog ordered by
priority, then use colours to see which tasks from which board are a higher
priority. But surely the point of having an ordered list of tasks is to see
which is the highest priority?

~~~
NotPaidToPost
Yes fixing bugs first is sensible, but you still need to prioritise projects
as well.

My point is that there is no need to lose the benefits of separate boards in
order to solve the (non-)issue of quickly finding out what to do next.

And if you have a single board then try easily seeing how product x is
going...

(btw, by colour-coding I meant features, bugs, etc. so you can immediately see
what's what)

------
jkmcf
I recommend story mapping[0..2]. It facilitates seeing your backlog across
goals and activities, which may span projects. With a more focused backlog,
you can then prioritize within specific scopes.

The main downside is tooling. Unless you are using a physical board, you'll
probably want/need a SaaS.

[0] [https://www.jpattonassociates.com/user-story-
mapping/](https://www.jpattonassociates.com/user-story-mapping/)

[1] [https://agilevelocity.com/agile-tools/story-
mapping-101/](https://agilevelocity.com/agile-tools/story-mapping-101/)

[2] [https://www.thoughtworks.com/insights/blog/story-mapping-
vis...](https://www.thoughtworks.com/insights/blog/story-mapping-visual-way-
building-product-backlog)

------
shireboy
It seems like it would depend on the number of projects and volume. If you
imagine a paper kanban board in an office, they may be right that you don’t
have one per project. Digital ones I typically think of (and use myself) as
one per project. Depending on the system you may be able to filter and have
the best of both. Tag the cards by project and filter when you want to see
just that project. Unfilter when you want to see all projects at a glance. At
some point it won’t scale, but that’s almost intentional. If you have too many
cards on a board it is a signal you don’t have enough resources or have some
other inefficiency that needs to be addressed.

Also depends on your definition of “project”. Maybe a better phrase would be
one board per -product-?

------
evrydayhustling
This is a factorization problem , like so many in engineering. Putting
unrelated things on the same board is expensive, because you have to
constantly compare those apples and oranges to prioritize, estimate multi-
ticket release dates, and so on.

Splitting things to different boards can also be expensive, because you have
to prioritize resources at a higher level across boards. And if you break up
dependencies, suddenly you have to flip between boards to answer questions.

It sounds like somebody was sick of the drawbacks in the second paragraph. But
maybe the issue isn't that you need a monolithic board, it's that you need to
make sure the boards are split in the right way.

------
IanCal
If you think things would run better if you worked on blocks of things at a
time, either see if it's OK for you to focus on one product/tech for a
day/week/whatever your preferred timeframe is. As long as you're taking
tickets from high up in the backlog, I'd expect that would be fine.

Otherwise, would it make sense to batch them when prioritising? Same effect,
but across the team.

Fundamentally, just try things and keep what works. It doesn't really matter
if that's not how other people do it (though knowing general approaches is
useful to see what to try).

------
qetuo13579
We have 8 engineers with different skills stretched over 6 projects. It is a
nightmare because all projects are top priority and late. We will be moving
towards tracking tasks per project and per engineer. Currently tasks are only
tracked per project which gives no visibility to what other projects an
engineer is already working on.

------
werber
My current team uses a digital board. We have the stories prefaced with the
system so they stay together. Devs typically work between 1 or 2 systems
during each sprint with about half of them being full stack. It works ok, but
there is a hierarchy of how fun each project is to deal with and people get
salty occasionally when they're stuck on old legacy stuff for multiple sprints

------
KrisBraun
Our full-stack teams work with stories that are demoable, thin vertical slices
of user-visible changes. While they can be broken into subtasks within the
story, we see the biggest benefit to full-stack development being the
ownership of taking the story to done across the stack.

------
rorykoehler
we have 2 boards. Ice box and product board. The product managers control
which tickets make it to the product board and what their prioritisations are.
We plan projects via spreadsheets in google docs at the beginning of each
cycle. It's not perfect and we're constantly working on it but I have faith
it's the best approach for us.

------
mikekchar
First, I think this is an interesting question. However, I would recommend not
asking directly about a work issue in a public place. It's kind of airing
dirty laundry and could possibly upset people unless you have advance
permission.

But to answer the question, it really depends on how you want to do it. If you
have a single team doing everything and everyone can grab any ticket, then
having a single backlog means that the priorities are obvious. I can't tell
you how much that improves the planning process and it could very well
override the problems with having a mixed board. If you are doing kanban, then
having the priority correct is pretty important.

If you have multiple different teams or multiple different roles, then it can
help to split out the overall board into streams. However, in my experience it
helps to have an overall priority list for as long as possible. If you are
using software to display the board, then it might be possible to
automatically split it into streams. Once you get too big, though, it becomes
impossible to do central planning for everything, so it becomes a moot point
afterwards.

Different people react to context switching differently as well. Personally, I
have literally 0 problems with it. Some people end up going something like
twice as slow if they have to context switch. The normal solution I've found
is to allow people who have a problem to cherry pick. If people start to game
it, then you might need a manager to intervene, but I've rarely had problems
with it.

When in doubt, talk to your teammates and come up with a compromise ;-)

