Ideal way of burning down stories on JIRA

Question

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- · Answer

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)

Jai Ganwani · Answer

@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.

Bill Sheboy · Answer

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