Some projects have feedback from many sources (testers, designers, customer, developers). You can easily get more than 50 different items that need to be prioritized. Some of them are huge, critical bugs; others are of the type "move the drop shadow on button X 1 pixel down".

What's a good way to organize this feedback so that it's easy for the product owner to prioritize items?

(Note: This question is similar to the unanswered part of Handling detailed feedback from many sources)

  • 1
    One hint that may help: the product owner should not see the minor issues like "move the shadow by 1 pixel". Product Owner should only work on user stories level and critical bugs. The minor issues can be handled by the team. This will take off some off the decision making time from the product owner, thus minimising the risk it will become a bottle neck for you. – Zbigniew Kawalec Jun 6 '12 at 10:37

Check out the cost of delay approach (original article is available here).

Although, the approach was designed for features, it also applies to defect prioritization (highest comes first):

  • Minimum to launch: those defects which practically blocks the delivery, or causes high customer dissatisfaction. For example, the application cannot be started, or the bill generation is wrong
  • Required to stay in business: those defects which the longer stay in the system the bigger damage they cause. For example, every tenth request fails. In nine cases it is fine, but after a while the failing request will cause some trouble
  • Bug/Feature to win/loose market share: those defects which has no harm at the moment, but will turn to "required to stay in business" after a while. For example, the twitter sign in doesn't. It is not a big deal now, but after a while we can loose important twitter using customers
  • Design investment: usually this is the category for improvement. For example, bad code quality related defects

Collect your defects and categorize them accordingly. Follow the business needs and the effect of the defects on the business.

This is how it looks like with images: enter image description here


Google has an interesting methodology for test planning that can lend itself to prioritizing the backlog. It is called ACC, shorthand for Attributes-Components-Capabilities. By defining your ACC and scoring the capabilities by risk, business value or whatever, you can develop a matrix that gives you visiblity into what you should work on first.



I've used a simple grid to prioritize e.g. risks, brainstorming ideas, etc. For detail prioritization you could use a 3 x 3 grid, one axis being cost/effort (rate as low/moderate/high) and the other being need ("Nice to have"/"Need to have"/"Critical to have"). Ask the sources to independently rate the items they gave you using these criteria, collate the results and put them up on the grid. An example from a risk management exercise is:

enter image description here

You should get a good idea of what you should prioritize at a macro level doing this, and you can modify the results a bit based on your business rules (e.g. customer's criticals come first) to make a sensible final list.

You can also develop rules for which details will be addressed and to what degree. In the risk example a business rule might be to accept risks in green boxes, mitigate those in yellow and actively avoid those in red. In your case, a low utility/high cost item would be scoped out, high utility/high cost items would be assigned your top tier developers, etc..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.