If I track time spent will the Burndown Chart burn, even if QA needs to mark an issue as Resolved?

Erik Johnson_gqcii3

For us, an issue isn't Done until it's passed QA, and QA likes to validate an issue in production before they mark it as Done. This leads to sprint burndown charts that plateau until the end of the sprint, then resolve all at once. And it means the development team doesn't have a simple visual sense of how they're progressing towards the sprint goal. 

I think Burndown keys off the last column in the agile board, right? Only when an item is Resolved does it affect the burndown. And philosophically at least, I think this is correct for our culture: we want everyone thinking that an item isn't really done until it passes QA. 

But at the same time, I'd love to have a burndown that actually burns. Our current system could be hiding information from us: I don't think there's an easy way to track how regularly the development team is moving items from InProgress to InQA, and we'd all like to know that. 

Is there a way to track status changes? If we start tracking Time Spent will the Burndown Chart show progress towards a sprint goal? Is there a better/different report I should be using? 

Thanks so much! I've spent 2 hours reading in the forum here and learned a ton, but figured I'd ask my question straight out. 

Maarten Cautreels

Hi Erik,

First of all I've added the Agile tag as this is certainly a discussion about process and not just about the tools you use.

So from what I've read you would like to have a burndown that burns down once an issue has been deployed to production (before QA has verified it). But on the other hand you need to keep your "official" burndown where it only burns down one an issue has been verified by QA. :-)

Process

On the process side, as a Scrum Master, I'd suggest you book a room and brainstorm with your team about your definition of done. When is your issue really done? Once a user can start using it in production? Or once QA has verified it?

Usually the answer is the second one as QA usually verifies issues on a Test or Staging environment. The way it works in my team is pretty similar to your process. We have a bunch of automated tests that cover the most important features for us before we deploy to production. After the deploy our QA does a brief check on production and reports any bugs that he has found. He does not reopen the features as they have been delivered correctly according to our Definition of Done.

Important to note is that we have a Bugs First approach in which our bugs automatically gets added to our sprint/top of the board and we pick them up asap. There we don't have the burn down problem. :-)

Tooling

On the tooling side, JIRA (Software) hasn't been build to support your use case but you could use it in a way that it kind of supports it.

You could create a second scrum board which is almost identical to your current board but just leave out the QA column(s). Make sure the "Deployed to Production" state is the final state in the new board. This way, the new board will give you a burn down that actually burns down once things are deployed to production while keeping the "official" burndown untouched.

Hope this helps, feel free to respond with any feedback or extra questions you might have.

Best,

Maarten