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 straightforward or as exacting as the definition I use with my teams.
Therefore, I’d like to share my simple philosophy about defining “Ready for Dev” with you here and now. Just note that this is more a philosophy for building team culture than it is merely a way to advance the work of a product.
My goal for refinement meetings is not only to move tasks around but also to encourage a feedback culture where everyone feels empowered to speak their mind, knowing that they are 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.
In the first weeks after someone joins the delivery team, I invite them for a 1:1 coffee at a neighborhood coffee shop. At that meeting, I lay out the founding principles 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.
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. I document the open questions within the description of the Jira task, as explained in this article with Jira task templates, to ensure they maintain high visibility.
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.
