Swinlanes
Last updated
Last updated
Swinlanes is an iterative product management tool without any attached methodology — it doesn't uphold any specific principles or values beyond enabling teams delivering customer value in a sustainable way. It's constructed like a Russian doll, mirroring the way developers, designers, and product managers actually build products. Individual contributors work within developer lanes to deliver feature iterations, which together constitute features. The main idea revolves around the triad of developer lane, feature iteration, and feature.
This triad is presented in two views, which can be toggled in the Swinlanes UI. The first view, called Swinlanes itself, displays the developer lanes with feature iterations assigned to each developer. Each feature iteration card remains immovable at all times. The second view, called Productbase, represents all the product’s features — it serves the same purpose for product requirements and specifications as a codebase does for code. Once a feature iteration has all its stages marked green i.e. done, it disappears from the Swinlanes view and can only be found in Productbase. But what are stages?
Everyone is familiar with working on a Kanban board: you create a ticket, drag it from one column to another, and occasionally reassign it to different people. Rinse, repeat, drag it back and forth. If you use Agile and your team has more than five members, every stand-up meeting might involve your product owner scrolling up and down the Kanban board, trying to find certain tickets in various columns assigned to different people.
With Swinlanes, this problem doesn't exist. Status changes are made not by dragging and reassigning but with a single click on the stage indicator. One click turns it from blank to flashing green, indicating progress. Another click marks it as done with a solid green. One more click sets it to blocked, and clicking again resets it to empty.
Currently, stages are workspace-wide and set when you configure your Swinlanes for the first time, allowing up to five stages. Five stages are equivalent to 15 Kanban board columns, providing a level of granularity that's hard to achieve with Kanban. Imagine your Kanban board having 15 columns, that would be a mess, wouldn't it? In Swinlanes, every stage has empty, in-progress, done, and blocked statuses. All stage names are editable, though we recommend keeping the last one named "Ready for Users."
The ticket mentality and inherent ignorance of Agile have ruined software development. Some orgs have a well-defined "Definition of Done" (DoD), which, when fulfilled, sends a ticket off into the void. This allows developers with weaker work ethics to check off requirements and relinquish responsibility for the code they've just shipped. Swinlanes suggests using "Ready for Users" without defining exact steps. If it's ready for users and you're not ashamed of what they see, that's sufficient — there's no need to clarify further. But what happens next to the feature iteration that's ready for users? Unlike tickets marked by DoD that vanish into abyss, they move into the Productbase.
