Practical Ideas for Efficient Backlog Refinement
Getting your developers to do their best means being sure that they fully understand and are invested in the product's user stories and backlog.
Join the DZone community and get the full member experience.
Join For FreeTurning an idea into a software is what IT companies do for a living, but only a minority make sure that they are not building the wrong product, or one with little or no value at all.
When management cultivates a culture of secrecy around the product being developed, and hands over just a piece of information to the delivery team, just enough to build the functionality they are supposed to work on, the team does not feel invested into the final results (because they don't know what the final results are), and lo and behold, the wrong product comes to life.
In Agile, the key event to ensure proper shared understanding and team's involvement is the backlog refinement. And if this event is conducted in a proper way, companies can not only a avoid building the wrong product but also build great products that customers love, with fewer expenses and even have loyal and invested employees!
And here is a recipe for that to happen…
Focus on The Most Impacting User Stories
The whole team (business and delivery) should be involved, early enough and on a weekly basis, in shaping up the product backlog by continuously challenging the wording, the outcome and the priority of the user stories.
Nevertheless, to set the ground for an efficient backlog refinement, the Product Owner and the Scrum Master should strive to foster an environment where discussions are open and transparent especially during the team’s formation phase or with a staff new to Agile.
During a backlog refinement, the first activity of a team, though, is to make sure that they start every refinement session with the top priority user stories with regards to the expected outcome vis-a-vis the customers and the company.
As a rule of thumb, it is a good practice to find collaboratively convincing answers to the following questions:
1. Is the team sure the user story on top of the backlog is the one with the best outcome and the highest value?
2. How can we measure quantitatively the success of the user story? What metrics can be applied?
3. Is the user story in line with the overall product vision?
Apply the INVEST Checklist Using a Questionnaire
Once the team is sure that the user story is of the highest value compared to the remaining items in the backlog, the team can apply the INVEST filter to assess its readiness.
The INVEST acronym is among the techniques recommended in Mike Cohn's User Stories Applied and for having using it can come in handy to have a ready backlog.
Applying this method will either lead to stamping the story as ready, or trigger a list of actions intended to improve its readiness.
The grid below is a suggestion of a simple questionnaire that can be applied to assess each criterion coupled with a list of recommended actions to be taken if the criterion is not meet.
Criterion assessment’s questionnaire |
Actions to be taken if one or more answers is/are negative(s) |
|
Independent |
Does the completion of the user story depend on another user story? Does all the needed information regarding the user story available? Can the user story be completed without the help of anyone else outside the team? |
Identify and prioritize the user story needed as a prerequisite Postpone the user story to a later refinement session Invite the right audience during the refinement (functional and technical) Have a complete cross-functional team before starting the implementation |
Negotiable |
Is the team free to choose the best and less costly way to implement the user story? |
Rephrase the user story to give more leeway to the team Stick with the "what", don't prescribe the "how" |
Valuable |
Does the user story's value easy to grasp? Does the team understand this value? If I put myself into the customer's shoes, will I be thrilled to see this story done? |
Rephrase the value to make it tangible. Rre-explain it to the team until they get it. If no real value can be found, drop the story. |
Estimable |
Can the story be estimated by the team? |
Break down the story into pieces, then go through the refinement activities |
Small |
Are the estimates not too large? Is the product owner able to clearly answer all the team’s questions? |
Break down the story into pieces, then redo the refinement activities Work out the unanswered issues by inviting the right audience |
Testable |
Does the team know when the story is done? |
Craft tangible acceptance criteria in form of test cases, to be written down before the implementation |
Timebox the Time Spent Refining a User story
In order to keep the on-going sprint productive, the refinement session must stay within fixed time boundaries. The recommendation is to set aside 10% of the time of a sprint for the refinement.
But to keep the whole event productive and worth the while, it is recommended to track the duration the team spent on refining each and every user story by mean of a timer (or an hourglass to give it a holy aspect). The stories taking more time than it should is more likely to be not ready and need definitely to be revisited later on.
Use the "Question Stick" to Get Everyone Onboard
The best way I have found to make sure the team is involved during a refinement session, fully understands a user story, and in the meantime has some fun, is what I call "the question stick".
Here is how it works. The team agrees on a single funny toy to use during the refinement session, and they call it "the question stick."
Every member of the team gets this “stick” and asks at least one question to the team or the product owner, and then passes the stick over to the next person. The idea is to cover everything related to the user story, and that each team member builds on his colleague's answer to seek more details. If the team feels that the user story still needs some more discussion, they can go for another round.
The questions could cover anything from applying the INVEST criteria to sharing a bad feeling about the user story implementation or warn the team about a hidden undiscussed roadblock.
Opinions expressed by DZone contributors are their own.
Comments