You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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 ?
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.
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.
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)