How to measure technical debt in a sprint (stories/tasks planned but not realized) ?
Hi,
Would like to know the best practice to deal with technical debt in an agile scrum iteration. I am using the out-of-the-box scrum template.
In case you planned for a sprint a story with 60 points with 3 tasks related (4 hours each). At the end of the sprint you concluded only one task and not the entire story. What should I do to measure this in an iteration ? Is there any report or widget ?
And another question is ...what is the best procedure for that?
1) close the story with updated points realized (eg. 20 points) ?
2) move the story for next sprint ?
etc??
Thanks for help.
Regards,
Sandr
Accepted answer
In the case where you had three tasks under one story, and only completed one task (not the entire story), your Burndown report should be able to show that you still had work items open at the end of the iteration. You could use this to interpret technical debt if the work items are not updated/moved to another plan.
In regards towards your question for the best procedure, this is tough. I would suggest whatever you do decide, make sure it is documented as a standard and used in all cases moving forward.
Since the first task was completed, and the others become the 'technical debt', you could move them onto the backlog. Otherwise if you bounce them around between different iterations they may never get completed, or may cause additional technical debt in other areas if your team pushes to complete them (and neglects other features). At least when they are in the backlog, you can re-evaluate them during your sprint planning.
In regards towards your question for the best procedure, this is tough. I would suggest whatever you do decide, make sure it is documented as a standard and used in all cases moving forward.
Since the first task was completed, and the others become the 'technical debt', you could move them onto the backlog. Otherwise if you bounce them around between different iterations they may never get completed, or may cause additional technical debt in other areas if your team pushes to complete them (and neglects other features). At least when they are in the backlog, you can re-evaluate them during your sprint planning.