I found that I like using “weight” as an indicator of criticality. In other words “how important is this?”. I think this can help direct effort because the product manager can identify the criticality of various items and the developers/engineers can identify the labor/time. Once you have both pieces of information, it will be obvious where to direct resources (to items with high weight:time ratio). Likewise, the burndown chart will be an indicator how much value is being added over time and/or how close you are to being ready to make a release.
As an example, you could have each of the following:
1 A simple bug that completely breaks your product for some users (high criticality, low time)
2a A new feature that many users are clamoring for (high criticality, high time)
2b A simple simple that is a minor nuisance for some users (low criticality, low time)
3 A complex issue that is a minor nuisance for some users (low criticality, high time)
You obviously want to focus your developers on those issues roughly in the order I have listed them. The burndown chart will drop quickly at first, then slowdown over time. At some point, the remaining items will just be of the #3 variety. That is the point where you may start to think about doing a release and deferring some of those issues to the next sprint cycle.