We have all heard that we should be doing something in the line of backlog refinement. It is meant to be a complement to the planning session.
But why do backlog refinement, and why is it important?
A lot of the material available seems to approach the refinement from the perspective of the story or feature itself. Saying things in line with X, Y and Z are important for the good of the story.
In this post, I want to highlight 3 things from different perspectives:
- One from the story or feature itself
- One from the PO or business side
- One from the team’s perspective
And yes, we get it. Most engineers just want to solve problems and not bother with meetings and politics and everything else going on. But there are a few reasons to why the backlog refinement should take place.
1. PO gets a deeper technical understanding of a feature (Business)
In some cases, you will have a very technical PO, who will have an excellent understanding of the inner workings of the service for which they are responsible. But in most cases this will not be true. On the surface, a feature might look like a simple thing to implement.
But unless you consult the technical expertise within the team, you will never learn about any potential troublesome dependencies.
By having the conversation with the team members as early as possible in the lifecycle of a new story or feature you minimise the amount of work you potentially have to scrap. #failfast
2. Make sure Definition of Ready is fulfilled (Story or Feature)
In contrast to this being the first instance where the team gets their hands on a new story or feature, it is also the final checkpoint before bringing it into a sprint or starting work on it. This means it is the last opportunity to make sure that all conversations that should be had before starting any hands on work has happened. This can sometimes come in the form of a Definition of Ready (DoR) checklist. And with DoR we refer to the story or feature being in a good enough shape to start working on.
- Make sure the DoR is fulfilled
- DoD
- Test cases
- Minimum implementation to solve the problem
- Identify dependencies
These are just some examples of what you can have on your checklist; it is ultimately up to the team what makes sense for them to have on their list.
3. Allow time for subconscious problem solving (Team)
Subconscious problem solving, what on earth is that? I’ll give you an example from my experience.
Back in the day when I was working as a developer doing planning and safety calculation software for airlines, we were conducting interviews to bring on some more people. One of the interview questions used was for the candidate to write pseudo code for a recursive string inverter. I wasn’t part of the interview process, but a close friend of mine was. At the end of the day, he posed the question to me. It was phrased in such a way that it made me feel stupid for not being able to answer him there on the spot (in my defence this was at the end of the day, and my brain was very close to a used up sponge). I refused to answer the question and told him to ask me again the day after. Roughly 30 mins later standing on the train together on the way home I had a eureka moment. Without giving the problem any further thought, the solution presented itself in my mind, and I could easily provide an answer to the problem on the commute home.
I have never experienced the effect of subconscious problem solving more clearly than that time. It is the same experience you have when you have good ideas in the shower, or on the treadmill in the gym, or any other place where you are not focusing on anything in particular but simply let the mind do its own thing.
There are techniques you can use to steer the mind towards things you want to put your energy into. It’s called priming. The refinement session acts as a priming session for people who are natural problem solvers. If you present the feature in a way that highlights the problem to be solved. i.e. present developers with problems to solve and not solutions to implement (this is a whole separate topic on its own), you will get the priming effect.
Final thoughts
The last point about subconscious problem solving and priming the mind is something I haven’t seen mentioned together with development work or ceremonies such as backlog refinement. But in my opinion is something that is very very important. By providing a broader understanding of why an organisation should do the ceremonies – makes it easier for us to motivate them towards all parts of the business.
If you are considering not having the refinement session for whatever reason. You have to, at least, make sure that you prime your problem solvers somewhere else. But don’t take my word for it. Try it out for yourself and make up your own mind. Experiment! That’s the whole point.