Ask HN: How does your team run the kanban backlog/board?

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.

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-?

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.

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

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 ;-)

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).

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.

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.

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/

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

[2] https://www.thoughtworks.com/insights/blog/story-mapping-vis...

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.

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.