I often advise teams against using a release burn-up (or burn-down) chart because I’ve seen too many managers try to use them as a stick to beat the team with their original pre-project release estimate. Since velocity changes from iteration to iteration, the size of the release needs to change, as well. Jim Shore has a great post describing how to do a release burn-up that takes into account changing velocity and the cone of uncertainty, giving a more and more specific estimated release size to burn up to after each iteration. Check it out.

Related posts:

1. One Word Can Change Your Daily Scrum
2. The Power of Small Experiments