Three Goals for Effective Backlog Management

I encourage all of our Delivery Leads to measure how effectively they are managing their backlog through the lens of three goals. These goals can be phrased as the following questions:

  1. Do you have four to six weeks of sprintable stories at the top of your backlog?
  2. Is your backlog completely estimated up to your next end-of-project milestone?
  3. Does your dev team understand the project goals through the lens of the stories in your backlog?

Read more on Three Goals for Effective Backlog Management…

Designing a Scalable Deployment Pipeline

Anyone who’s led a product engineering team knows that a growing team requires investments in process, communication approaches, and documentation. These investments help new people get up to speed, become productive quickly, stay informed about what the rest of the team is doing, and codify tribal knowledge so it doesn’t leave with people.

One thing that receives less investment when a team scales is its deployment pipeline–the tools and infrastructure for deploying, testing, and running in production. Why are these investments lacking even when the team can identify the pain points? My theory is that it nearly always feels too expensive in terms of both money and lost progress on building features.
Read more on Designing a Scalable Deployment Pipeline…

Why Estimate Bugs and Chores in Your Backlog?

When we’re running a client’s project using our Atomic Process, our team will assign an estimate of points to each item in the product backlog.

In general, we classify backlog items into three buckets:

  • Features (new or enhancements)
  • Chores (dev work not resulting in tangible product changes)
  • Bugs (fixing unexpected behavior or regressions)

Read more on Why Estimate Bugs and Chores in Your Backlog?…

On Writing Technical Content

During the past few months, I’ve taken on the daunting task of collecting some of the important software development lessons we’ve learned at Atomic over the past decade into a body of writing about the size of a handbook. The goal is to capture the ideas in a way they could be easily shared with a new Atomic developer, so as to build a common framework for having conversations about our dev practices here. We’re excited about this resource, and we plan on sharing it broadly when it’s completed.

While working on this project, I learned a few things about managing time and energy by breaking down tasks, categorizing them, and understanding the environmental and time constraints of each type.

Organizing My Work

Once I had an initial outline and a couple of rough chapters, I created a Trello board to track tasks and filled it with everything I could think of that needed doing. Each task was something that would take somewhere between 30 minutes and 1/2 a day to complete. To avoid distraction, if I was working on one task and realized something else that needed to get done, I’d add it to a backlog list in the Trello board.

Read more on On Writing Technical Content…