Building products at scale - The Backlog (Part I)

Years ago, I wrote about how I would run a software development shop. As I now have a chance to put most of those thoughts into practice I am greeted by the next set of challenges in my career path - how do you actually build a product.

With a few exceptions, the majority of my career was dedicated to delivering projects in a consultancy. This started shifting recently in my last roles at Microsoft. Turns out, even an organization like Microsoft has incredibly varying views on how to build products. So, as an exercise, I started writing down some thoughts on things I’ve seen work well.

Filling the Product Backlog

The Product Backlog is familiar to everybody who has ever touched an Agile approach, or at least read about it. It contains units of work that are committed to by the team and delivered in iterations. But how those units of work come into existence and are worked on, varys.

The approach that resonates with me the most is that each new product backlog item builds on the previous one by narrowing the scope. It does so by introducing more details - and it achieves that through cross-discipline collaboration. I've seen successful implementations of this in teams I admire - like .NET, Azure and Visual Studio. This also has a few benefits for planning which I'll touch upon in one of the next Parts of this series.

You start by defining a super broad scope, called a Theme. This is something that leadership defines based on company strategy, partner collaboration, market need, etc. It doesn't matter where it comes from, but it needs to have supporting data associated - be that signals, telemetry, customer research. Let's say we're building an e-commerce shop. A Theme would be "Increasing purchases".

Then, the scope is narrowed, and Epics are defined by Product Managers and Domain Experts. We're starting to understand what those broad themes encompass. Our PMs have identified that in order to increase purchases, we should consider "Expanding Payment Providers".

We continue refining the scope further, identifying Features that we need to deliver to achieve our theme. Continuing our example, let's say we need to add "PayPal Support".

Finally, we can start writing User Stories - the smallest* unit of work. Now we understand in depth what we have to deliver and who we are delivering the value for. Now we can define concrete stories like "Enable purchasing item with PayPal", or "Enable cancelling a purchase made with PayPal", etc.

*sort of smallest, as we also have tasks, but they aren't really PBIs (Product Backlog Items) as such

Refinement Sessions

To break these units of work down, we need to refine them. A lot of Agile practitioners will use the phrase grooming, but I passionately hate that word. Anyway, refinement includes working with stakeholders and across multiple disciplines (like design, technical writers, even product marketing) to add more context to the work item, thus enabling it to be understood and broken down further.

These sessions need to happen continuously, across all the levels, from the bottom up:

• Leadership defines the Themes, then works with PM leads to convey what the theme is, how its success is measured, what the drivers are, etc. The result of these sessions are Epics.
• PMs or PM leads, depending on structure, now take the epics and further refine them with one or multiple PM/POs. Low fidelity design work can already start, helping the team visualize the end result. The result of these sessions are Features.
• At this point, PO/PMs further break down this task, add work from other stakeholders (i.e., a higher-fidelity design, writing drafts, etc.). Then, they collaborate with the Engineering Leads to break this down into User Stories.
• Engineering now starts understanding the stories, estimating them with the relevant team members, etc. When this and all collaboration is done, the user stories are ready and moved to the relevant place in the backlog.
• As User Stories end up in the sprint (i.e., after planning), individual engineers can break them down into Tasks to help convey progress.

The nice thing about this approach is that it can (and should) happen in parallel. As Leadership defines a Theme, they move it along the board and start working on the next one, and so on and so on… This provides a nice input into the Agile cycle & enables continuous delivery from a process perspective.

From an Engineering lead perspective, though, what this translates to is that User Stories that are deemed Ready and are on the backlog will:

• be well understood & estimated by relevant members of the team,
• have design-work finished,
• have a clear, well-defined scope along with an acceptance criteria.

In fact, what this translates to is that each PBI in its respective layer will be well defined, understood and enriched by all contributors before it can be moved on in the board.

Cross Discipline Collaboration

There is a reason so many sayings exist about the same thing - like, "Too many cooks will spoil the broth". Too many people getting involved too early (or even too late) in the process will often result in a waste of time. Too many ideas get surfaced and logically, most of them are ignored, leading to bad morale, disappointment, etc.

A structure like the one I am talking about ensures that there are clear stakeholders for each unit of work, and thereby, each part of the process. That translates to always knowing exactly which stakeholder to involve in refinement sessions thus not wasting anybody's time.

Concretely, in the pyramid representation I used above, the person owning the area below is always accountable and the person owning the area above is always consulted (if accountable and consulted are new terms, click here for an explanation of the RACI matrix). For example, breaking a Feature into User Stories is led by an Engineering Lead - they own that process, but they always work with (and are accountable to) the PM who defined the Feature. Developers are consulted however, as they are key stakeholders in the next part of the process.

Each PBI also has a Definition of Ready. For different units of work/PBIs, that will obviously be different. Looking at a Feature, I'd define it Ready when it is

• scoped - has a well-defined and understood subset of work to be done,
• outlines POCs and architecture investigations needed,
• Low-fidelity design work is complete,
• Technical Writing is planned & defined and is
• T-shirt sized.

There are a couple items to unpack here in this list. To say that a Feature is well "scoped", the person picking it up next (i.e., engineering lead) has to be comfortable with understanding it. The Engineering Lead also plays a crucial part in outlining the POCs and architectural concepts needed.

This might be the first time we're starting to see more disciplines show up. Design Teams get involved, and low-fidelity work (akin to engineering POCs) might be planned or done, before the feature is deemed Ready. The same goes for any other disciplines the organization might have (like technical writers...).

Prioritization matters

As I’ve said before, I’m a huge believer in having a prioritized backlog. This does not only apply to user stories but to every single PBI. That means that Designers, Technical Writers, etc., also have a clear structure to work against - they pick the topmost item in (their view of) the backlog. This ensures that everybody is always working on the most important thing (from the leadership perspective).

There are additional benefits to the proposed structure - time/strategical/hierarchy alignment. In most organizations, there’s a structure in place that resembles the following (ignore the names, they will differ, obviously):

This structure let us easily map the units of work to each level. Epics and Features fall more on the right side of the tree (i.e., Product side) and User Stories and Tasks fall more into the Left side of the tree (i.e., Engineering side).

The final side-effect here is that it also provides for a natural pairing when working on issues. Engineering & PM Directors will collaborate a lot. It’s also only natural that engineering leads will collaborate with their partner PMs. We can even go so far as to anticipate that "bubbles" will emerge that specialize in a specific domain/area of the product. You can go further and dedicate an Engineering Lead to such a bubble, along with a PM. Now you have both the domain and technical skills focused on an area. Additionally, supporting (but key) roles are assigned as well - like design, ensuring that best practices are followed for each individual area.

These bubbles can follow whatever structure works best - in Visual Studio for Mac, as an example, I was part of the Editor team. We had our own dedicated PM, our engineering lead, and we specialized in delivering one small subset of the product. We followed the general release cadence & sprint timings, but we had our own planning, retrospectives, etc.

Not only bubbles, but each role (potentially) has its own view of the backlog, and what’s better, they can prioritize the unit of work that they own according to their view of the world. If FeatureA is broken down into 4 user stories, and FeatureB is broken down into 3 of them, the engineering lead might (in collaboration with the PM/PO!) prioritize UserStoryA3 and UserStoryB2 into the sprint first, because the architecture lends itself well to getting those done and delivering value immediately.

In Part II, we take a look at how this leads into a nice planning cadence...