Doing vs defining work

The last software development team I worked in had a couple of problems that plagued their backlog refinement sessions. I tried to help by explaining and making explicit that there is a distinction between doing work and defining work.

There were some psychological factors and poor incentives at play: the team had been burnt by making small estimates on tickets that then turned out to be much larger than expected, and they had a fear of looking like they were working slowly. And that contributed to the failure to treat an estimate as an estimate. They couldn’t really handle the fact that it might turn out to be wrong, which is of course the nature of estimates.

The first way this manifested was that, without them noticing, the discussion for what needed to be done for a ticket would get increasingly in-depth, and before they knew it they were looking through the code trying to figure out how it worked and exactly what changes would need to be made to implement the ticket. And secondly, when faced with an unclear spec, they wanted to nail down all the ambiguity before starting work. Whereas my approach is that it’s fine to say that part of the work is finding answers to the outstanding questions.

So during a backlog refinement session, I want to capture what’s currently known and unknown, identify questions that need to be answered, and make an estimate of how much work will be needed to do those things. (And if there’s a lot of uncertainty, I have no problem with creating a spike ticket to answer those questions and then re-evaluate once that’s done.)

The way I think about all of this is that this is the process of defining work, which is based on what you know now. The backlog refinement meeting is for defining work, and if you need further information then gathering it counts as doing work. Having that distinction in mind can help you to notice when you’re trying to do the work in the refinement meeting.