How can agile business analysts incorporate feedback in a controlled way?

We believe that it is important for agile business analysts to create feedback loops everywhere. This gives the business or your clients or your product owner frequent opportunities to give feedback on your understanding of their requirements and feedback on the software being developed. It also gives developers and testers opportunities to give feedback on requirements from their implementation perspectives.

However, with all of these opportunities to gain feedback an agile business analyst could end up with a huge number of items to manage, so it does raise the question:

How can agile business analysts incorporate feedback in a controlled way?

Product feedback, the product backlog and triage

If you are using Scrum then the product backlog is the obvious mechanism for managing feedback items. When any item of feedback comes up about the product then you can simply add that item to the product backlog. Scrum defines the role of the product owner and this person is able to make decisions on behalf of the business for the project. So as new items are added to the product backlog it’s then up to the product owner to prioritise the new items of feedback against everything else on the product backlog and decide if and when to make a change in response.

While this is an effective and simple approach it can still get overwhelming. You may be having interviews with the business every two weeks or more and people may be coming up with ideas for product development left, right and centre. You may be getting feedback on everything from "we should have this whole new capability" to "I think that field isn’t aligned properly" to "the button should be a different colour". As you can see an agile business analyst could end up with a product backlog with hundreds of items and this quickly becomes unmanageable for a product owner.

In our experience a product owner is never going to cope with accurately prioritising a product backlog with more than a few tens of items. So triage becomes very important. As items come up, they get triaged and may get categorised into low, medium or high priority. In this way they get assessed at some level before they just end up in a big, unmanageable pile.

Rapid feedback reduces the magnitude

The sooner you get feedback the easier it is to incorporate it, as so this can make it easier to manage. Agile business analysts should seek very quick feedback to validate whether their requirements will deliver the expected business value. The agile team needs to get quick feedback that their code meets the stated requirement. If you catch something that doesn’t meet the requirement while the developer is still developing then it can easily be changed. Compare this to finding this problem once that code is going through testing or gets released into production, where the problem becomes much bigger, much more costly to fix, and a much larger item to manage. Agile practices such as acceptance test driven development (ATTD) can provide very rapid feedback on whether code meets stated requirements. The aim should be elicit feedback earlier and action it straight away to avoid managing large backlogs of tasks.