Practical Ideas for Efficient Backlog Refinement

Turning 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.

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.