Taking Plane for a Test Flight — Can It Fly Higher Than Jira?
Plane is an open source alternative to Atlassian’s much-maligned (by developers) Jira work management software. Perhaps because of Jira’s reputation, Plane has quickly attracted the attention of developers. Co-founder and COO Vihar Kurama describes the product as “a simple, extensible, open source project and product management tool powered by AI.” He says it allows users to start with “a basic task-tracking tool and gradually adopt various project management frameworks like Agile, Waterfall, and many more.”
To be clear, I am one of many people who have encouraged people to use Atlassian products (BitBucket, Confluence, and of course Trello) while pushing them away from Jira. Like all true critics of a product, I do still use and respect Jira, of course. You can only truly dislike what you know well.
As companies advanced through their agile adoption, the Kanban board (sometimes just cards stuck up on a wall) became the poster child of the movement. It was the physical evidence that agile was happening, much like confetti is left around after a wedding. Jira, unfortunately, was designed as a type of cross-organizational component vision of software — with a set of fairly inflexible use cases. The term “misconfigured Jira instance” became a common refrain as it slowed down over time.
Jira started out as a bug and issue tracker, and kind of stumbled into the agile management explosion. I saw this quote on ycombinator, and it sums up the problem well:
The first problem is that everyone, even in the same team or org, needs something different from Jira. Sometimes it is even single individuals needing one particular thing one time, and the same day for another workflow or view another thing. It is when Jira caters to the wrong use case for you right now where a lot of frustration arises.
The agile world is now fairly stratified, like those Kung Fu films where different Sensei(s) hole up in mountain retreats, practicing their brand of fighting while disdainfully dismissing the others.
Plane isn’t by any means the first open source project in this space, but it is late enough to be able to get into AI. In this article, I’ll just look at the product, and touch back on the business case at the end.
First of all you can run a Plane server in docker — I’ve no real idea why you’d want to do this per se, but it does go with seeing it as an open source component. The product itself has been carefully engineered, although getting the backend solid is just table stakes. It worked perfectly smoothly as I went through it.
I started with a Plane cloud account which is surely the sensible route for most projects. You can sign in with GitHub or Google; I chose the latter.
After a very short time we are introduced to Issues as the basic building blocks. It then mention Cycles, which appears to be its version of sprints. Modules are another issue container. (Plane says it is not attempting to enforce agile, but they are happy to use that language sometimes.)
Confronted with a nice dashboard, I created a project:
Obviously, we must now actually think about a set of tasks to implement. So let’s go with a simplified website.
- Get domain name
- Design website
- Deploy
I’m purposely comparing this with an agile project management, which it doesn’t have to be. I’m also aware that Plane isn’t a finished product. At this stage, I would imagine the project will shift towards where the greatest mass of users are.
Now, I know the world of Plane is made of Issues, so I’ll start there:
Note that the shortcode “FIR” was created for issue numbering. Hence my first issue is FIR-1. Smart move.
Before I continue, let me fill in a few expectations. Most people reading this will know very well what an issue tracker does within an agile-like project, but let me refer to the right-hand side properties from the image above.
An issue, once generated, will probably appear on a backlog. This implies that, while understood, it isn’t about to be worked on. A team member could then assign it to themselves to work on. They will work on it within a sprint (but we already suspect these will be cycles). The work must be planned within some type of task and given a priority within that, after the stakeholders have assessed the work. Designing the website will clearly have the highest priority in my list.
All work should have an estimated time to complete and thus a due date — otherwise planning becomes a bit difficult. And any issue can have tags or labels purely for organizational reasons. The parental relationship between issues is much like a biblical family tree. Fixed widths begat mobile size errors; Back button begat lost context, etc. Bugs do tend to Go Forth And Multiply. Similarly, blocking issues are relationships that exist in parallel to the issues themselves. From the perspective of Plane development itself, these always have the potential to upend models, because relationships between issues have to keep checking if the issue itself still exists.
Looking behind the State property, we find five possibilities:
Five possibilities.
In reality, these are not static positions, but more of a state machine. For instance, if an issue goes from “Done” back to “In Progress”, that tells a very specific story that we might need to investigate later. “Cancelled” is also a bit of an oddity here — it isn’t really a valid pipeline position. If an issue isn’t deleted, it should return to the Backlog.
It is important to understand that an issue exists separately from any work that is made to fix it. Quality Assurance (QA) views issues as extant behavior — and it is really only QA that truly should ever state that an issue is no longer present. From a developer’s point of view, when they finish a fix associated with an issue, they are indeed “done”. But those viewpoints are subtly different. This is why if the same errant behavior reappears, developers will think of it as new work to fix it, but QA will see it as the same issue reoccurring.
So to kick off, I create my first cycle. This is the organization container I will put my FIR-1 issue in:
I was given a start date and end date, but that “7 days left” is not quite the same as an estimate. Obviously, not every consecutive day will be dedicated to the task — especially weekends. Having a specific end date is a bit “Gantt-charty”, whereas we do need to know how much work is needed to complete a task against days estimated. Anyway, I associated my issue with a cycle, and gave it a priority:
Medium priority.
Priority is always a bit of a crapshoot in agile. In the end, a manager will always assign things they care about as “urgent” until the project is well grounded. At least a simple priority like this is understood in general by everyone. Stack ordering in the end is a better place to head for.
Meanwhile, the Comments/Activity section accurately summarises all my actions. This is good.
I was hoping the pages would offer a wiki-like note-taking facility. They use blocks much like Notion, with AI to help structure your thoughts. But they don’t seem to quite work as yet. I’m sure I can move pages to issues, but can’t see how. The idea of generating issues with AI needs some care; this is not the place for hallucination.
Anyway, I turned all three steps of my web page project into issues and then assigned them to myself. Plus, I will add the design task into the design cycle. I will also add some labels to differentiate the teams likely to be involved later. Cycles don’t seem to impose end dates for issues within them, which is interesting. Indeed, an issue can have a “due date” different to the issue due date. Maybe modules do this, but I didn’t look at these. Indeed due dates can be in the past, but woah, let’s go gently here.
Finally, I set up some views. These are quite an important point for a project, because they allow all the stakeholders to judge progress together. These don’t quite work yet — they are just filters. So I can’t quite make a “burndown” view of completed issues; I can see ‘Done’ issues but not as a percentage of in-progress issues. (To be fair, the Dashboard has a graph that does this anyway)
I created a new issue, which was generated from another issue. In fact, I created a new issue first and then linked it. I would prefer to generate from the parent issue; I could do this as a sub-issue, but I missed that the first time.
You can see a list of issues as cards in their swim lanes — like a Kanban board, or like a calendar Gantt-like chart. In Kanban mode, you can make this nice summary — which is prettier than just making things really tiny.
Obvious tools such as importing from Jira and Slack integration are marked as “coming soon.” These are surely necessary — and for that reason, they are very likely to truly be “coming soon”. In reality, very few projects will just jump ship from Jira to Plane halfway, but eventually, teams will want all past issues on one platform.
Overall
I’m happy to have looked at this, but from a product perspective, I think I have looked a little too soon. I suspect a large company may well take this code and work at it to make it sparkle a bit more.
Plane feels like an open source toolkit that needs a dedicated direction stamped on it. We all know agile is not one thing, but we don’t need alternative names for “sprint” really. Having notes with AI is less important than grounding the basic features. I hope in a short time this will blossom into the natural successor in the space. But there is a weary lesson to learn from Jira; focus on one set of features, or you will have to be satisfied with just being the least worst.
