Your backlog is an imperfect, always changing, self-fulfilling prophecy for how your software will be built. Not only that, but at a software consultancy like Atomic, it’s also a prophecy for how the engagement will end and deliver on your brand promise.
All this to say: Tending to the backlog is one of the most important activities development leaders can engage in to ensure a project goes well overall.
(Every software team needs someone responsible for feasibility, technical constraints, system architecture, etc. At Atomic, we call this person the tech lead, so that’s the term I’ll be using in this post. You can read more about different roles on Atomic project teams.)
Your Backlog Is the Product
As the feasibility steward of the project, the tech lead is responsible for ensuring that the product and the project accurately incorporate technical constraints and efficiencies. For a feature to be viable to the business, it needs to be implemented within a reasonable budget. For a feature to be valuable, it must meet user needs. The tech lead serves to bridge these concerns by testing designs for reasonable implementation approaches that can deliver value in accordance with cost, as measured in development time.
But the implementation cost of individual features is only part of the story. As the project progresses, the system evolves in a macroscopic way through the implementation of individual features. How this evolution is guided and informed can make a crucial impact on the project’s ability to deliver on goals. So while developers need to implement the features modeled in user stories, they must do so in a way that evolves the overall system toward medium- and long-term goals.
But even this is only part of the story. When the project is over, who will be maintaining it? Will they have the tools necessary to pick it up and deliver bug fixes or enhancements in a reasonable way? What artifacts might they need to continue development? And how will they identify and diagnose operational issues?
An Atomic project results in more just a piece of software. There’s also a line of development continuity that must be handed off, or at least archived for revisiting in a future of uncertain iOS upgraded and dependency evolution. The tech lead must worry about and deliver on all of these concerns and more.
The backlog is an invaluable tool for continually refining the plan to address these concerns by the end of an engagement. While our customers often think of hiring us to deliver a software artifact, we look at the holistic engagement as the product. Our backlog is our plan for everything we will deliver throughout our engagement with a client.
As big-picture and long-term concerns are discovered or clarified, the tech lead models these concerns into the backlog. The tech lead works as a tinkerer, capturing insights as notes that add color and clarity to our plans to address these concerns.
You might imagine a note here to simplify maintenance as part of implementing a user-facing feature, and another note there to reduce the risk of rework by drawing attention to future needs. Stories evolve as they move their way up the backlog, and the tech lead’s job is to create the clearest possible picture of how we should approach our plans to address changing needs.
As tech leads manage the backlog, they need to collect and document the relevant knowledge about the design and tech stack, follow the innovations of the development team, and trawl the backlog for future and past related work–all while keeping an eye on the broad progress of the project and the long-term plans. When the tech lead maintains this broad awareness, individual members can be free to focus on the task at hand.
The Implementation Hypothesis
Through this work, a story becomes sprintable (a.k.a. ready). A sprintable story should have as few unknowns as possible. The UX and edge case states should be designed. Relevant past work or future stories which might relate to this story’s implementation should be noted. Any “known unknowns” should be documented, and any constraints on solutions should be clarified. Ideally, any developer picking up this story to implement will have a clear path forward, and any information that should impact their approach will be close at hand.
As stories are clarified and the desired result becomes more constrained, it’s useful to provide an implementation hypothesis outlining the best-known approach. This hypothesis is a sketch of an expected solution for meeting all of the story’s current needs and setting it up for continued success on upcoming work. It might show existing work which can be leveraged and illustrate a strategy for streamlining future work. It should be as detailed as possible and draw attention to areas where detail is not yet understood.
Implementation hypotheses allow the team to make precise time estimates of the work required with the maximum possible accuracy during sprint planning. The whole team should be comfortable with knowledge that these time estimates are committed to only to the extent that the implementation hypothesis is inaccurate. The challenge to the team is to either prove the hypothesis correct and deliver within the estimate, or disprove the hypothesis early and let the tech and/or delivery leads decide how to react to the missed expectations (by going over budget, splitting the story, relaxing constraints, or deferring).
The tech lead often leads the development and maintenance of implementation hypotheses during backlog refinement, but not always. Once the relevant connections to the big-picture plan are clear, an experienced feature lead may take over the detailed breakdown and planning of stories for new subsystems or complex areas within the application. The tech lead’s job is not to create the implementation plan, but to ensure that stories are sprintable before they’re considered for sprint planning.
Friday Tasks and Chores
As the development team executes, they’ll surface technical debt that’s accrued in the gaps between implementation hypotheses and actual code. This is inevitable, and it’s not a problem at moderate levels. Ideas for automation, refactoring, and architectural changes will surface and need to be handled. These often don’t fit within the scope of the story at hand.
We prefer to have a Friday task board where any member of the development team is free to add ideas that can improve the health of the codebase. We usually build some slack time into schedules on Friday for miscellaneous todos that accrue during the sprint.
However, many of these ideas are not merely miscellaneous todos, but important bits of context related to upcoming work. The tech lead therefore triages “Friday tasks,” on the lookout for important and/or substantial items that should be estimated and added to the backlog, or that are directly relevant to upcoming work and should therefore be part of a story’s implementation hypothesis.
In the end, it’s only minor, truly miscellaneous items that remain as Friday tasks. Since developer time is the primary constraint on most software projects, time dedicated to properly estimated and prioritized work should be maximized. “Friday task” time isn’t fully vetted and analyzed for cost-benefit tradeoffs, so it should be treated with care. As much as possible, bugs and chores should be estimated so that such trade-offs can be evaluated.
A Tech Lead’s Best Friend
Ultimately, the backlog is the most powerful tool for managing all of the challenges of the tech lead role. It serves an a GTD-style inbox for all of the new insights and concerns that spring up over the course of a project. Any time a new worry surfaces, you can capture it in the backlog and rest assured that the Agile process will find a way to resolve it before the end of the project.
It’s a todo list, a powerful communication mechanism, a subtle prioritization tool, an approximate predictor of the future, and more, all in one place. It’s both a predictor of the future and insurance that future results will approximate your project goals. With effective use, it’s the key tool in running a project effectively.