Software Triage

Writing out a recipe makes it real really quick. There’s a new level of precision required: quantities, time, technique, and the order of operations all have to be recorded in a way that someone else can follow (and succeed).

You’ll hit similar snags while translating software needs. There’s some extra incentive, though, since blown timelines and burnt out developers sting more than a burnt entree. Implementation hinges on an application’s “recipe,” and recording those steps — “tickets” for developers — is another requisite project process. Toss it on the pile.

How do we make requirements actionable?

Triage, borrowed from the medical field, puts a name to the act of assessing and sorting priorities. As an exercise, decision-makers tend to take one of two stances:

1. “I don’t want to touch that.” Triage doesn’t put the fun in software development.
2. “What’s the big deal?” Triage feels like it should be a simple task.

There’s a big gap between those two. Where’s the rub, and who needs to contribute?

Application Needs are Collaborative

Triage is hard because it (almost always) requires more than one person:

• Someone brings the business context: what’s needed and why. We’ll refer to these folks as stakeholders.
• Someone adds the technical context: how to get there and how long it’ll take. We’ll call these talented individuals tech leads.

So, two or more people, collaborating on some of software’s tallest hurdles: direction, estimates, priorities, ownership, and measurement. Expertise comes from both sides. Compromise, too.

Let’s take a look at each role, their responsibilities, and what they need to be successful.

The Stakeholder Role

Business context sets stakeholders apart. That means — hinging on organization size — we’re usually talking about a founder, an executive, or someone with “product” in their title. Much subject matter expertise here (or access to it).

What Stakeholders Bring

Stakeholders are the source of what’s needed and why. They’re relied on for:

• Problem statements. What are we trying to solve? We’re not worried about how to handle the problem just yet, but there’s an underlying customer need or goal to address.
• Decision-making power. Once the potential solutions to that problem are laid out, stakeholders shoulder the responsibility of picking a path.
• Purchasing power. The last piece of red tape is always budgetary approval.

What Stakeholders Need

To close the loop on decisions and direction, stakeholders need a few pieces of information:

• Options. What’s possible? Can we grab things off a shelf? What would a custom solution get us? Decisions rely on mapping the problem statement to technical options.
• Time and cost. What would each of those options take? Budget and calendar time help put a value to each direction.
• Future impact. Is this meant to be thrown away, or are we prepping for future iterations? Value is also flavored by longevity and maintenance.

The Tech Lead Role

Technical context is the other side of the coin, governed by a role we’ll call “tech lead.” In most cases, the responsibilities here fall to a senior developer or a former-developer-turned-manager.

What Tech Leads Bring

How does a tech lead arrive at the how of problem solving? They show up with:

• Opinions. System selection is hard, and keeps getting harder (if that’s even the right direction in the first place). Success stems from research, experience, word of mouth, and some magic developer intuition.
• Questions. Where is the problem statement light on details? There are always edge cases, alternative paths, and uncertainties to explore.
• Related problems. Will solving this problem introduce new ones? Is there a looming, cascading, butterfly-effect-like danger to other features? Platform complexity likes to pretzel its way into knots.

What Tech Leads Need

Wrapping all of this up, tech leads look to others for:

• Business context. What’s the issue worth to the organization? Is it a fire, an annoyance, or a hunch? Developers’ opinions are influenced by characteristics like immediacy and impact.
• Access. Stakeholders shouldn’t stray too far from the implementation work: Follow-on questions are a given, and someone has to produce the stamp of approval later.
• A green light. It’s disheartening to toss solutions over a wall and never hear back. Someone with decision-making power has to commit and say “go.”

Approved To-dos

There’s friction in all of this, naturally. Stakeholders are looking for the mythical intersection of good, fast, and cheap. Tech leads want to avoid net new complexity and any “temporary” adds. The right answer isn’t always somewhere in the middle.

Collaboration feels like a lot of talking and not a lot of doing, leading time-sensitive managers to wince at words like Discovery — but it’s still a necessary step. “You’re not discovering, you’re de-risking…”

The net result is the list of actionable tickets (the recipe) we mentioned back at the beginning. Let’s explore some of the theory and pitfalls around ‘em.

Triage Examples in the Wild

There’s no shortage of how-tos for effective ticket writing. Many center on ideas like:

• User stories (“as a [persona], I [want to], [so that]”) and the follow-on Gherkin methodology
• Jobs to be done (“what an individual really seeks to accomplish in a given circumstance”)

At industry leaders like Pivotal, this task falls to a product manager and an experienced engineer. Is it perfect? No, but there’s no universally-accepted truth here, and every team will be a little different. As starting points go, you could do worse than pairing up these two specializations.

Tangentially related: Will Larson talks about the Navigator pattern, which gives an engineer ownership over an area and the responsibility to align technical decisions with organizational strategy.

Where Tickets Struggle

Not all recipes are created equal, and tickets have their own gotchas to look out for.

Estimates for Others

Story points vs. hours vs. any of the other estimation flavors out there is a nuanced topic we’ll put on the back burner for now. As a process, though, estimates tend to be unique to the person making it. Throughout, developers consider:

• Their familiarity with the codebase
• Past experience with similar features and requests
• Uncertainty around requirements

Two engineers generally won’t arrive at the same number of hours or story points, and holding the implementation team to someone else’s estimates is a blown budget waiting to happen. Ideally, developers are working against their own assumptions.

Minor caveat: Comparing two different estimates is great for identifying gaps in understanding.

Not Enough Detail

Assume that the next person reading this ticket (even if it’s you) has no prior knowledge of what’s inside. There’s a good chance it’ll all fall out of your working memory after a vacation, a weekend, lunch, a conversation, a coffee run, or a quick task on a different project. Even if it’s a meal you’ve made before, you’ll probably need to check the recipe.

Finding the right amount of detail is tied to experience, and it’s usually proportional to the effort needed.

Too Much Detail

As you might’ve guessed from that last sentence, it’s definitely possible to provide too much detail. Quality takes a hit when:

• Developers don’t have room to do the right thing.
• Ticket writers aren’t fully clued in to what’s possible or the “state of the art.”

The implementation team will always find room for improvements and polish. Should they follow those instincts, or stick closely to the requirements?

Absentee Stakeholders

There are questions during triage, after triage, during development, after development, and off into the future. If a stakeholder fades away after the first step, they’ll return to a mess: unanswered questions, wasted effort, and an incomplete task. A tight feedback loop keeps all of this on track.

The Lure of Interesting

Developers have a tough time prioritizing tickets. There’s hard-to-resist, flies-in-bug-zappers draw towards issues that are either small or interesting. It’s easy to fall in the short-term trap and lose sight of long-term goals.

Organizing tasks by importance (and with a deadline) avoids focusing on quick wins for too long.

Translating Project Needs

We kicked this article off with a pair of observations: triage isn’t fun for most, and it seems harder than it should be. There are plenty of reasons why:

1. It takes two (or more) people to make an informed call.
2. We’re wandering through all kinds of competing methodologies: waterfall vs. agile, user stories vs. jobs to be done, story points vs. time, and a host of other “best practices.”
3. There are so, so many tools out there to learn and try.
4. There’s no perfect way to do any of this.

Above all, triage is a communication problem. But with the right people and well-delegated ownership of issues to tackle, most of the work is done.