Ideal way of burning down stories on JIRA

[Jai Ganwani]

Hello Community,

I know that JIRA follows DoD and burndown happens once when stories are move to the "Done" column. I have a scenario wherein my Definition of Done is that the story should be completed and the developer has to perform atleast one round of testing on the completed story before marking it to done. Assume the story points given to this story as 4. Now, due to some reason the developer was able to complete everything but was not able to finish one round of testing and that is the only thing that needs some effort. IN this case can I reduce the story point of this story from 4 to 1 to show the leftover work that is remaining. I would like to know what should be the ideal way to burn down stories ? 

TYIA

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Burndown is a binary measure, either a task is done, or it is not.  When your developer doesn't manage to complete the issue during a sprint, you should leave the estimate as it was, to inform people how much was estimated to begin with, and then let it roll over into the next sprint, where the developer can burn it down when they're genuinely done.

[Bill Sheboy]

Hi @Jai Ganwani 

Yes, and...to Nic's answer:

When the sprint completes and the team sees the goal was not met, or more / less than expected was completed, that is great information for the team to take into the retrospective.  They can ponder "why" and select experiments to improve in the future, such as adjustments to backlog refinement, sprint planning, improved delivery methods / quality, focus and WIP, etc.

Kind regards,
Bill

[Jai Ganwani]

@Nic Brough -Adaptavist- Is it ok to do a Mid Sprint Review and drop stories out of the sprint ? This is kind of replanning because the developers may need to work on new bugs that are entered on the board.

[Nic Brough -Adaptavist-]

No.

If you're replanning, your processes are broken, and you're not able to plan for the future.

It's fine to do a mid-sprint review, but it really should be about "how is the sprint going?".  New work is an irrelevance during a sprint - it's nothing you committed to doing, so it should simply go into the backlog.

However, when you have a team that does often have to pick up immediate support, the best way to deal with it is to anticipate it as you go into each sprint.  Don't bother with "mid-sprint reviews", just look at the average estimate for the support work and incorporate that into the sprint commitments (for example, if your velocity is around 100 SP, and you usually lose 20 SP to support issues, then the team should only commit to 80 SP, because they know they're going to have to absorb another 20SP)