How to Tackle Ill-Defined Technical Work

So you’re humming along as a member of a decently performing team, knocking out user stories in your well-managed backlog. But when you go to pick up your next story – surprise! — you get a technically-focused task that’s uncharacteristically lacking in definition. It’s not clear where to start, what to do next, or whether this will take four days or four weeks to complete.

What do I mean by technically-focused? I’m thinking of things like, “Refactor internal data syncing logic,” “Optimize background data import,” or “Integrate new payment gateway.” In my experience, even with an experienced product owner/backlog manager, these types of stories are too often neglected with respect to definition and refinement.

This doesn’t seem to happen with user-facing stories, which are more likely to have a visible need defined by the product owner, user experience designer, and key stakeholders. People are usually more aware of (and more opinionated about) user-facing work, so these stories garner more attention and receive more refinement in your backlog.

Don’t panic! Follow these steps, and you’ll get through your backlog item successfully while effectively managing your team leader’s expectations.

1. Identify a Research Path

You’re going to do some time-boxed research to gather knowledge about this undefined work. This is analogous to user or product research that could inform how to build a user-facing feature. But instead of talking to end users, maybe you:

  • Talk to another developer or two on your team.
  • Research third-party tools or vendors online.
  • Build out a couple of throw-away spikes to better understand the feasibility of a potential direction.
  • Read through a lot of your team’s own code and try to diagram or design an alternate implementation.
  • Do a combination of these.

The goal is to identify the tasks that would yield the most knowledge about options for moving forward with the amorphous backlog item.

2. Get Permission

Discuss your plan with your product owner, determine a reasonable allocation for the work, and decide how to track this effort in the backlog. The goal here is to set expectations: I’m going to spend X hours/days researching options and get back to you with what I find.

3. Do the Research

Document what you find as you go, and when you’re done, synthesize what you learned into a summary. Then, based on your new understanding of the situation, outline a few options for how you could move forward and tackle the backlog item. Think of these as mini plans of attack.

4. Present Your Options

This meeting should include your product owner, the lead developer/architect, and anyone else you think would have an opinion about how you should move forward.

Your presentation should include:

  • An outline of your options.
  • A rough estimate of how long you think each option would take. This could be in time or points, depending on how your team estimates.
  • Your opinion on which option is the best one to pursue.

Your goal should be to reach alignment on which, if any, options the team will move forward with and when that should happen (e.g., now or next sprint).

Execute!

Finally, you’re back where you wanted to be in the first place. You have a well-defined body of work, which your team leaders agree is the right thing for you to be doing right now.

Happy coding!