Branches to Backlogs: Implementing Effective Timeframes in Software Development

A few years ago, at my previous company, I found myself on a familiar quest: hunting down a specific Jira issue. What I discovered was both amusing and alarming—three versions of the same problem statement, each with different solutions spaced four to six months apart. Every solution was valid in its context, but the older ones had become obsolete.

This scenario is all too common in the software development world. New ideas constantly emerge, priorities shift, and tasks often get put on hold. As a result, the same issues resurface repeatedly, leading to a chaotic backlog with multiple solutions for identical problems. This clutter makes it challenging to grasp our true roadmap and impedes our ability to achieve objectives.

Digging deeper, we found hundreds of issues languishing in our backlog. In a rather humorous yet sobering realization, our back-of-the-envelope calculations suggested it would take over eight years to address all those features.

From this experience, we concluded that any issue left unresolved for over six months should be deemed outdated and permanently deleted. If a problem remains unsolved for that long, it likely needs to be revisited and addressed from scratch.

Based on these lessons, I'd like to share some best practices to help you manage your development process more effectively.

‍

Issues in Backlog: No Longer Than 4 Months

Trello Recommends Regular Backlog Grooming to Keep Issues Relevant and Actionable

Why It's Important?

Issues that linger in the backlog for more than four months often lose context and priority. Regularly grooming the backlog ensures that the team focuses on the most valuable tasks and avoids unnecessary clutter. You can read more about how Jira recommends backlog grooming here.

When the team is aware of the age of a Jira issue, it encourages them to be more mindful of prioritization and to spend their time more effectively. Regular reviews and a four-month limit on backlog items help maintain a clear, actionable roadmap and ensure that outdated tasks are addressed promptly.

Techniques such as weighted scoring or the MoSCoW method (Must have, Should have, Could have, Won't have) can be useful in prioritizing tasks effectively.

Backlog ages like milk, not like wine

‍

‍

Branches: No Longer Than a Month

GitHub Recommends Regularly Merging Branches to Avoid Merge Conflicts

Engineering Leader: "Jamie, what’s the status of this client request?"

Developer: "It’s all done, currently in QA. It should go out in a day or so."‍

A week later:

Engineering Leader: "Jamie, did we push this feature to the client?"

Developer: "Sorry, it’s waiting for another feature due to some merge conflicts."

If you’ve ever experienced this, you know how frustrating it can be. Regularly merging branches can prevent these delays by ensuring that code conflicts are addressed early, maintaining code quality and keeping the development process smooth.

Keeping branches open for more than a month can lead to significant merge conflicts and integration issues. Regularly merging branches helps maintain code quality, reduces technical debt, and ensures that the team is working on the latest version of the code.

‍

Best Practices for Managing Branches

1. Frequent Integration

Integrate changes at least once a week, if not more frequently, to ensure your branch doesn't diverge significantly from the main codebase and avoid merge conflicts.

2. Small, Incremental Changes

Make small, incremental changes rather than large, sweeping updates. This makes it easier to integrate and review code, reduces the risk of conflicts, and speeds up and improves the review process.

‍

‍

Epics: No Longer Than a Quarter

Atlassian Recommends Breaking Down Epics That Can Be Completed Within a Quarter

The higher up in the hierarchy, engineering leaders rely heavily on epics to understand where the team's efforts are being invested. Often, I’ve noticed that some epics, like those for technical debt or enhancements, end up containing hundreds of issues. These catch-all epics bloat badly because engineers are forced to associate every issue with an epic. As a result, it becomes difficult to distinguish between efforts spent on roadmap items versus technical debt or KTLO (Keep The Lights On) tasks. This leads to epics dragging on for years, making tracking progress difficult.

Long epics can become unwieldy and difficult to manage. Teams can maintain momentum and deliver incremental value by ensuring that epics are completed within a quarter. This practice also facilitates better planning and tracking, ensuring that large projects are broken down into manageable parts that can be tackled effectively. Read more about this on Atlassian's guide.

‍

‍

Best Practices for Managing Epics

1. Define Clear Boundaries

Ensure each epic has a well-defined scope and objective. Avoid using catch-all epics by creating specific epics for distinct tasks.

2. Regular Review and Pruning

Regularly review and break down large epics. Move completed tasks out and create new epics for ongoing work to keep the list manageable. For example, you can have a tech debt epic for every quarter.

3. Prioritize and Categorize

Clearly categorize epics based on their purposes, such as roadmap items, technical debt, or KTLO. This helps in tracking where the team's efforts are being invested.

4. Limit Epic Duration

Set a time limit for how long an epic can remain open. This ensures that long-term tasks are broken down into achievable milestones, facilitating better progress tracking.

‍

By managing epics effectively, engineering leaders can gain better insights into the team's workload, ensure that efforts are aligned with strategic goals, and reduce the risk of bloated, unmanageable epics.

‍

Tickets: No Longer Than a Sprint

Scrum Recommends That User Stories Should Be Completable Within a Sprint, Usually 2-4 Weeks

One of the challenges in agile development for both developers and managers is dealing with issues that spill over from sprint to sprint. In sprint 1, 20% of the work is done; in sprint 2, 30% is completed, and so on, but some issues always get carried over. The story points for these issues keep changing, setting wrong expectations for product managers and stakeholders. This can be demotivating for developers as it feels like progress is being stalled when, in reality, the ticket is simply too large for a single sprint.

Instead, these large tickets should be treated as epics, broken down into multiple issues, and spread across sprints to set the right expectations. Keeping tickets manageable within a sprint ensures that tasks are bite-sized and achievable, leading to more predictable progress and faster delivery cycles. This practice also helps maintain team morale and clear focus. Ideally, each ticket or user story should deliver value to the end user and be independently complete within a given sprint.

‍

‍

Implementing these time-based best practices can significantly enhance your software development process, ensuring that projects stay on track and deliver value consistently. By keeping tasks and initiatives timely, you can maintain focus, reduce waste, and drive continuous improvement.

‍

‍

‍

‍