Normally I’m very wary of “investigation” or “research” cards in a delivery team. Sometimes there are pieces of development work that are difficult, but I usually find that when a team raises an “investigation” or “research” card it’s because they are avoiding doing the actual work. The question I always ask is: What difference will your research make? And then: What would happen if we didn’t do the research, and just went straight into the development? Often we find the research won’t save time. After all, we are always making decisions, evaluating options, and trying ideas when we do any development. That’s just a natural part of the activity.
But a while back I was working with a team that used this early phase to good effect. I found out they were doing something called “research” ahead of a piece of a development, and I asked what they expected the output to be. I am generally unhappy with an initial answer of “it will help us understand the problem better”, because understanding is inside someone’s head, and doesn’t make a tangible difference to the world. In fact, the lead developer had an answer that made me very happy: “I’ll produce some detailed user stories for implemention”.
Producing actionable user stories is a very useful output. In fact, many teams find writing these things is sufficiently non-trivial that they put aside regular time for it; many of those teams call this work “refinement”. This particular team understood their system and user needs well, so rarely needed to block out “refinement” time, but when there was a need for it—as in this case—they happened to call it “research”.
In fact, you might say this is a very small version of the discovery phase of a project, although it relates to a tiny part of a project, not the project as a whole
All of this is a good reminder to me that investigation cards and research aren’t always bad ideas. But it doesn’t change my belief that worthwhile research should have an output that not only has a net-positive impact, but which is tangible, too.