The desired outcome of a product backlog refinement meeting is to move tasks from the backlog into the Ready for Dev column. But what is the best “Definition of Ready?” Reading around the interwebs leads to many definitions to this term, “ready,” but none of the ones I’ve found are quite as simple or as exacting as the definition we use in my team.
Therefore, I’d like to share my simple philosophy about how to define “Ready for Dev” with you here and now. Just note that this is more a philosophy of how to build team culture than it is simply a way to advance the work of a product.
My goal for refinement meetings is not merely to move tasks around, but to encourage a feedback culture where everyone feels empowered to speak their mind and to be comforted that they can do so in a safe place.
The problem with many definitions of “ready” is that they put all the pressure on the product manager to define the requirements, which inhibits the team’s empowerment to participate in the shaping of the product direction. My definition makes the requirement-shaping a shared responsibility. A conversation.
I am addicted to coffee, so one way that I encourage an atmosphere of openness between my delivery team and myself is to invite each member for a 1:1 coffee at a neighborhood coffee shop in their first weeks of joining the team. In that meeting, I lay out the founding principals of my management style and my expectations for how the team should challenge the status quo. A key point for discussion over coffee is this Definition of Ready:
Ready for dev is when every question has been asked, and every open question has been satisfactorily answered.
Until that time when every knowable question has been answered, tasks are not ready for dev. Any questions around scope, motive, priority, why the work is being requested, or how the results will bring value to users or the business are all fair game to be asked by all members of the team. Once all is understood, and all challenges have been considered, the task will be of the highest possible quality and advanced with the appropriate priority.
At that time when this definition is satisfied, and not a moment before, the work can begin.
If I, as a product manager, can not answer these questions, then I also don’t yet have full enough of a grasp on the task, and therefore it is reasonable to consider the task not ready.
This often leads to tasks needing to be refined several times until they are ready for dev. The homework gets done outside of the refinement meeting. Individual team members are consulted and dependencies are identified. I try to do everything I can to prepare the task before the refinement, but without fail, when more people get a chance to ask questions, they always find holes and give me more work to do.
I find it very constructive to walk away from a refinement with a checklist of open questions. This helps me scope out what I should be working on until the next refinement.
Most valuably, the team is more invested in the process, the product direction, and feels empowered to play a more proactive role.
What is your definition of ready? I encourage you to leave a comment and share how you approach refinement meetings and reaching the “ready” state of your tasks.
Preview my new book now and learn how to:
Just let me know where to send it!