Backlog Refinement – How I Learned to Love Agile Business Analysis

By Duncan Evans

Backlog refinement

The problem: confusion, uncertainty and delays

We find this a common thread amongst our customer teams, which can be attributed to a lack of backlog refinement.

A team are planning their next sprint. One of the developers looks anxious:

“What do you mean we are changing the way we list items? This is going to be messy – does finance know? Well fine, we can do it, but it’s not on me when we have to roll back.”

Sound familiar? When the detail of what needs to be built gets decided too close to development, the integrity of your flow of requirements from idea to reality becomes sensitive to small events. The above statement is paraphrased from a real developer on a team building a financial research product. Someone was out of the office for one day, and a decision was made in their absence because “we needed to get on with it”.

A team are reviewing the work completed in the last sprint:

“It’s the end of the sprint but these features are not ‘done done’. I guess we’ll have to carry them over (again).”

It is perfectly normal for a team to miss their forecast now and then. If it happens most times, there is a very good chance that the following pattern has been established:

  • Sizing is done during sprint planning.
  • There is no time for the detailed task breakdown or solution design that can help teams forecast effectively.
  • The team may not feel accountable for improving their forecasting and refinement practices.
  • Planning is painful and cyclic because the no one understands the stories

A team are refining their backlog ahead of sprint planning:

“We forgot to submit this feature for SecArch review, so we’ll have to postpone it for a couple of sprints”

External dependencies increase complexity and ideally development teams should have the skills and mandate to handle architecture, design, and security reviews themselves. If you are not there yet, a mitigation is having clarity over what is coming and what needs to have been done by what stage.

The solution: backlog refinement

In other words, detailed business analysis, documented well, organised effectively, and executed at the right time. Backlog refinement is a general term encompassing all of the analysis that takes place before the work is started. This might include:

  • A regular meeting with the whole team to estimate features and agree acceptance criteria;
  • Smaller groups working on test plans, architecture, and design;
  • Individual specialists preparing information to be discussed with the team;
  • Anything that helps the team plan and forecast effectively before they start the work.

This is bad news if you interpreted the line in the agile manifesto “individuals and interactions over comprehensive documentation” to mean “just make it up on the fly without having to come to any boring meetings”. The level of detail required to bring a successful product to market is broadly the same whether you employ traditional or agile methods; it’s just a question of timing. In waterfall, all of the analysis is done up-front, which takes time and makes responding to change difficult.

Conversely, taking an agile approach means Go to the full article.

Source:: Business 2 Community

Be Sociable, Share!