 | Product Refinement |
(“Grooming the Backlog”)
Good backlogs don’t simply emerge as you populate them with tasks. Tasks must be “refined,” meaning that the information they contain must be specified with the proper level of detail – no more, no less. This process is called backlog refinement.
As noted, it is crucial that tasks include the right amount of detail: enough for developers to know their options but not limiting their ability to apply their creativity and expertise, enough for them to have a meaningful discussion on how to move forward, but not so much that there is no room for flexibility, or that they are cumbersome and difficult to conceptualize quickly.
The amount of detail will also depend on whether a dev team discussion has occurred yet, and whether the task in question is high on the priority list (i.e., it will be built soon). The further away the item will be built, the less detail it should have.
DO NOT OVER-PLAN
Progressive Refinement
Progressive refinement is a process of breaking down items into smaller, more precise elements, as more detail emerges about the item in question (input from stakeholders, feedback from the dev team, etc.). Inherent in the concept (within Agile) is that the refinement happens only as needs emerge; never before. Always consider this principle when deciding how much detail to include in a task at any given time.
Last Responsible Moment
One of the most essential concepts in Agile is the Last responsible moment (LRM).
Your product will change while it is being built. Since you will iterate often and get feedback from stakeholders, you are expecting, even wanting changes (read “improvements”) to occur. The market will also be changing while you build, and you want your product to adapt quickly. You don’t want your team to waste time (and the salary you’re paying them) by building things that will be scrapped. This kills team motivation. No one wants their work to be scrapped. They also don’t want to build something that is released to the market and is adopted by almost no one because technology has moved on. Making decisions at the “last responsible moment” decreases the amount of work that will be scrapped and increases everyone’s confidence in the current, unfinished state of development. People like to know where they are going. They like to think that whoever is steering the ship knows how to reach the final destination. When they see that the plan isn’t completely fleshed out, they will need assurances that the lack of planning is intentional and even strategic. Otherwise, they’ll be looking for a life raft.
How can you be confident that you’re neither under- or over-planning? Consider the 20-30-50 Rule.
The 20-30-50 Rule
The 20-30-50 Rule is a rule of thumb for determining how much detail to include in a story. It breaks tasks down like this:
Top 20% – the stories that the team will be tackling in the immediate / near future
Middle 30% – the stories that will be tackled in the mid-range, needing just enough information to discuss and begin planning for
Bottom 50% – remaining, lower priority stories that should be recorded as a place-marker and acknowledgement that basic elements have been thought of. They need only include a short description and should not be over-developed.
Finally, understand that the Product Owner’s job is to constantly clarify the problem, and the Dev Team clarifies the solution. It can take multiple meetings for a PO to present a story to the Dev Team, for the Dev Team to ask questions from the PO (that the PO couldn’t possibly expect), and then for the PO to look for answers in preparation for a second round of meetings. This is in contrast to a “waterfall” approach to development, in which the PO might have pressure to lay out a full problem and a full solution to the development team. This may seem more logical at first, but it doesn’t take into account the very iterative nature of development. Both the PO and the Dev Team must embrace the original uncertainty and work collectively and iteratively to bring about innovative solutions.