In our Scrum there is a common phenomenon whereby the burndown chart does not represent well the team's progress. Most of the way into the sprint, only a third of the stories are closed, and the bulk of the remainder gets resolved in the past couple of days. This makes the burndown chart opaque, and not very useful for tracking sprint's success.
The main reason for this opacity is not team's unwillingness to close tasks, but rather the fact that we close stories only when they have been validated and demoed (as they should), and the validation process involves an unwieldy build installation/deployment which may take a few days from the point where the developer completed the code changes. The install/deploy cycle could be shortened, but the nature of the business we're in (network appliances) can never make it very fast.
I'd be interested in best ways to deal with this. The options I was thinking of were:
- Just ignore the burndown charts, and use other metrics to track progress.
- Separate coding and validation tasks into separate stories (obviously, not very clean, as the point of a story is to provide customer value). In other words, promote tasks into stories, and stories into mini-epics.
Is there anything better?