Kanban for Software Development: What Trello-Style Boards Get Wrong
Real engineering work is nested. A board of flat cards throws away the structure that makes it navigable.
The basic Kanban board — cards in columns, drag left to right — came out of manufacturing, where each unit of work is roughly the same size and shape.
Software is the opposite. A card labelled “build the payments integration” holds weeks of work across several engineers, dozens of subtasks, and dependencies on auth, frontend and DevOps. Dragging that card to Done tells you almost nothing. A board built for engineering treats hierarchy and cards as complementary rather than mutually exclusive.
The problem with flat cards
In Trello and its descendants a card is atomic. It has no real structure inside it. Checklists are the standard workaround, and they're a bad one: checklist items can't be assigned, estimated, statused or tracked.
You end up at one of two extremes. Cards so large they're untrackable, or a board of hundreds of micro-cards where nobody can tell which small task belongs to which feature. Both are the same failure — the structure exists, and the board can't hold it.
Kanban as a lens over a hierarchy
The fix is to let the board render whichever level of the tree you care about. A parent can sit in In Review while its children are still In Progress. Drill into one epic and see only its stories as cards.
The hierarchy never goes away; Kanban is a view of it, not a replacement for it. Engineers can live on the board for daily status while the PM works in the outline to see the whole shape of the project.
Either the cards are too big to track, or there are so many that nobody knows which feature they belong to. Both are the same failure.
Columns that match the real workflow
Most engineering workflows have far more than three stages: Backlog → Refined → In Progress → In Review → Testing → Deployed → Done.
Each of those boundaries is a real handoff between real people — PM to engineering, dev to reviewer, reviewer to QA, QA to deploy. A board that only offers three columns forces the team to track the interesting transitions somewhere else, usually Slack.
When Jira is non-negotiable
Plenty of teams have to use Jira. It's company policy, or three other teams depend on that board existing.
Tasks created in Taskpend can generate Jira tickets, and status updates come back. The roadmap and planning live in the richer interface; execution and reporting stay where the organisation expects them. No double entry, no drift between the two.
Make blockers visible or they don't exist
Software Kanban fails quietly when blockers are invisible. A card sits in In Progress for four days waiting on a design decision, and the board cheerfully reports it as active work.
Flag the task as blocked with a note about the dependency and it surfaces in filtered views. At stand-up, filter the whole sprint to Blocked and work the list — which turns blocker handling from a reactive scramble into a two-minute routine.
Takeaways
- Checklists inside cards are not a substitute for real subtasks.
- The board should render any level of the hierarchy you choose.
- Model every real handoff as a column, not just three generic stages.
- Blocked has to be a first-class state or it stays invisible.
Taskpend is a nested outliner with mirrored tasks, six views and AI agents that execute. Free for individuals.