As CTO, I’m constantly seeking ways to improve how we build and deliver software. After a few painful release rollouts riddled with delays, defects, and cost overruns, someone suggested we need a better project management tool to improve things. Linear is a product gaining a lot of traction, a minimalistic but feature-packed project management tool designed to streamline specifically software projects, sprints, tasks, and bug tracking. It is popular among engineering teams, so I tried it out. I must say that it’s pretty good — it offers a clean and efficient UI, making it easy to collaborate and stay organized.
While trying out Linear, I realized that great products require great tools and great processes. Implementing new software might have given us potential, but we should have aligned on improving the process most effectively as a team. Otherwise, we wouldn’t gain the much-needed improved visibility and communication.
Organizing software development is challenging
Roadmaps and OKRs start simple. You have a plan for the following year’s goals for each quarter. But things get messy over time. As you start building features, the scope grows. You make decisions and cut scope where possible. But bugs pop up, delaying releases. Deadlines slip.
After a few releases, it gets more complicated. New requests come in to modify or add features. The initial simplified scope now needs work to make features fully useful. More bugs are now reported by users.
This creates a lot of stress for engineers and frustrates stakeholders. It’s critical to stay organized to know priorities and status, which takes cross-team effort. Product managers provide business context and priorities. Project managers work closely with engineers to help them stay on track. Complete visibility into what’s going on requires critical views and reports.
Quarterly roadmap
The roadmap outlines major features the team aims to deliver over the next few months. It includes a mix of initially planned features and new priority requests from users and stakeholders.
One of the main functions of the roadmap is to provide estimated delivery dates for features. These dates should account for the time needed for testing, final bug fixes, scheduled platform updates, and other steps required before users can access the features.
Engineer effort estimates are essential for an effective roadmap. They should estimate the effort and time required for every work item they undertake. While estimates may be rough ballpark figures, each task should have an estimated due date on the calendar. Engineers should also provide effort estimates on a simple 1–5 scale. A 1 is a very quick, simple task, while a 5 is highly complex. Effort numbers between 1 and 5 add nuance, like a 2 is straightforward but not trivial, and a 4 is complicated but feasible.
These dates and effort estimates help the product and engineering teams understand the level of effort and timeline to deliver each roadmap item. They allow the manage to plan and allocate resources properly. The estimates should be somewhat conservative to account for unforeseen issues that often crop up during development and testing.
The roadmap’s clear and up-to-date dates and effort estimates keep stakeholders aligned on priorities and timelines. They aid coordination between product and engineering teams. With a well-constructed roadmap, the team can execute strategic objectives and deliver maximum user value.
Prioritized backlogs
The roadmap should be paired with a prioritized backlog of bugs and user requests. Bugs can come from QA testing or end-users but need processing and prioritizing. Not every bug is critical — some can sit in the backlog for years. The same goes for user requests — capture and log them all, but not everyone needs addressing immediately.
What matters for bugs and requests is that they get prioritized and reviewed regularly. Since users report bugs and submit requests through many channels, no matter how much you try to funnel them to one entry point, each request should be added to the main backlog for review. We struggled with this — working on bugs that can wait, not logging user requests in the system, then losing track of them, and failing to reprioritize bugs and requests on time.
Steps required in the process
For everything to work well, there should be a few critical steps in the development process:
Planning
A team needs a clear roadmap each quarter. If you decide to take on user requests beyond our roadmap, add them to the roadmap so everything is tracked in one place. The roadmap should list estimated delivery dates (requiring developers to provide estimates and project managers to keep them current). It’s okay to update estimates as time passes, but we should also log the reasons for changes to analyze later.
Tracking Requests
You can track bugs and requests together or separately. But log all requests in the system, review and prioritize weekly, and treat approved requests like features — provide estimates and update them. It would be best if you did the same for bugs, too — you can’t blindly work on every one QA finds important.
Weekly Check-Ins
The above provides visibility into the current status. Here’s what’s prioritized and where each item stands. Based on the initial analysis (which isn’t perfect, to say the least), the team started this feature on Tuesday and estimated 2 weeks. After user research, mockups took 2 weeks longer than expected, so a manager extended the estimate. The tech analysis provided engineer day estimates, updating the timeline again. In week 1, the team learned X, changing the estimate yet again. Then, a higher-priority request came in, so the manager adjusted the timeline accordingly. And so on.
Ideally, you also need weekly snapshots of the roadmap and feature status. They capture the shifting nature of things and help perform a retrospective analysis of our work.
These process improvements help us leverage our current project management software (Fibery.io). Features still take longer than we estimate, priorities shift constantly, and users always want more. But we can now adapt and realign quickly based on the actual data. Just as importantly, transparency improves team morale and collaboration. Developers are more bought into commitments when the process is inclusive and estimates are transparent.
Don’t assume new tools alone will fix underlying issues. Evolve your processes, workflows, and culture first, then complement them with software solutions chosen to enable the desired working methods. With a balanced focus on process and tools, you can build products efficiently and to high quality while keeping stakeholders and engineers aligned, informed, and motivated.
Originally published on Medium.com
