Creating a Risk-Adjusted Backlog - Mike Griffiths

This resource first appeared in issue #59 on 29 Jan 2021 and has tags Strategy: Project Management, Strategy: Product/Service Management, Technical Leadership: Other

Creating a Risk-Adjusted Backlog - Mike Griffiths

Here’s an example of a concept that I think research software development teams probably “get”, if implicitly, more than teams in other environments.

Research software development spends much more time further down the technology readiness ladder; we spend a lot more time asking the question “can this even work” than we do “when will this feature ship”. The risks are higher, because most promising research ideas simply don’t pan out. So we spend a lot of time prototyping, fully aware that the answer to “will this work” could well be “no”.

Griffith’s theme is that even as you march up the technology readiness ladder to more and more production code, you should still be explicitly prioritizing risk-mitigation tasks on the backlog rather than just prioritizing the most valuable feature. That might be code cleanup, it might be doing research on uncertain new steps way earlier than seemingly necessary, it might be documentation - it depends on the risks you’re worried about. In our context it might include going to conferences and giving talks about your tool, if the risk is lack of adoption.