Attacking Technical Requirements in Agile Backlogs

I was sitting in a meeting today where we were trying to capture architectural requirements for a popular SaaS product. There were mostly architects (software, network, and hardware) in the room and myself.

We started out talking about critical components of our existing system and how our current coupling made us more fault intolerant than we needed to be. Component cohesion, dependencies amongst specific components, services and systems was one of our most challenging concerns.

We began tackling our Product Backlog development by simply listing functional changes we wished to make. For example, we wanted to realign our authentication scheme to more align with customer groupings than a singular customer database. This would allow us to segment our customers in various models that would allow for smarter administration, group handling, and independent scaling.

It struck me in the meeting that these weren’t well-formed backlog items at all, as they were too narrowly focused. The other thing we were doing was aligning it with our technical intentions and with our challenges. So essentially, we were coming up with a wish-list of technically-driven product enhancements. Which is nice to have, but not truly a well crafted backlog. So, what weren’t we doing?

Start with the Business Perspective

Even though this was arguably a technical exercise, we should have started by driving them from a business perspective. Determining what sorts of customer problems were we trying to solve. What was the overall scope and impact of those problems-so order the work from a business perspective. Minimally this should be captured in a clear set of goals.

When you’re considering technical changes, clearly articulate the cost as well. Is this truly a necessary change in scope, function, and behavior? Run a gold-plating check to ensure that it’s truly required vs something simply nice to have. Clearly we should have invited business-facing folks to the meeting to serve as a customer-facing foil for our technical discussions.

Think in Terms of Delivery

We initially began prioritizing simply by what we thought were the most important or most sensible things to implement early on.  Quickly though, it dawned on me that we needed to think of how we would couple feature sets together from a customer delivery perspective.

How would these changes be packed? How would the new features partially or fully replace the existing features? Was the upgrade path clear? And was it simple and easy to understand?

When forming your technical backlog, think in terms of bundling, delivery and even documenting your work. Considering these aspects will significantly help you order the list, but also bundle work into clear and valuable themes or chunks.

Think in Terms of Testability

Another perspective that is helpful comes from simply thinking of how you’d test the deliverables. Testing coverage is one area to consider. How would you drive, end-to-end functional testing along the way while developing the backlog? How long would the testing be for each phase of the delivery and is that the most time/cost effective approach?

This focus on testing efficiency, how to prevent overly redundant testing, and build a testing strategy that aligns with the construction strategy is critical to represent in the workflow represented in your backlog.

Let Things “Cook” for a While

Quite often we want to make an immediate decision. We have passionate discussion and healthy debate. Usually a few voices are louder than others and then a “final” decision is made on the backlog. General enthusiasm then drives immediate action.

I’d prefer to let the backlog sit for a bit. Allow folks to stew on the details and think about the ordering-getting team members, technical and non-technical, to review the backlog and refine all aspects of it.

Remember that each backlog item needs some notion of doneness or acceptance associated with it. This helps to clarify the focus. This time can allow folks to refine the backlog from that perspective as well.

Finally, How About Working Code?

A final consideration is to not develop a technical backlog in full detail. Instead, develop it in terms of epic stories and develop some clarity around a single deliverable. Then, instead of hammering on the backlog, hammer out some working code that instantiates those important aspects of the backlog.

You’ll gain a sense of confidence and knowledge by doing this. You’ll also gain insights into the cost of execution that you can leverage in sizing and valuating subsequent work.

Technical backlogs are often attacked differently than functional or feature-rich backlogs. I think this is a large mistake many make. Hopefully this post has helped to broaden your approaches.

Don’t forget to leave your comments below