Progress in an agile project is usually recorded using a burn up chart when a story is completed. But when is a story complete?
Technically a story is completed for inclusion in the burn up chart when it is checked in, has had a desk check, has been independently verified to meet the acceptance criteria (usually by a tester), and is visible on the test server.
While this provides the most surety that the burn up chart reflects reality, it delays important positive feedback for the programmers on the speed and quality of their work – their velocity.
One approach flies a little against traditional thinking if developers are old school and won't help do testing and you have a bottleneck in the “Ready for Test column”: collect the story points in the burn up chart once the code has had a desk check and is committed to source code control. After all it could be weeks before the test team get a chance to verify the acceptance criteria in detail. In this scenario you could alternatively keep a second burn up chart if you need to (e.g. “Programming burn up” and “Testing burn up”) but try and give feedback to the programmers as quickly as possible.
Tip: Stories generally only travel in one direction in the swim lanes of the story board, from left to right. They don't move backwards (from right to left) even if a bug is found against the completed story. Developers get confused when completed stories re-appear or the burn-down chart becomes a burn-up chart.
For example, if a story has been desk checked and is already deployed on the development server but under certain conditions the acceptance criteria are not met, it is OK for it to stay frozen in the “ready for test” swim lane with a red sticky note flag on it until the bug is fixed. It does not get moved back to the “in development” swim lane unless the bug is so severe that the code has to be rolled back. If a story is in production but a bug is found against it, it doesn't get moved back into development. It's already in production!
