Tip 1 — Technical Debt vs UnDone Work
We all are very much well-versed about the term technical debt and Undone work in scrum.
If you are a scrum practitioner who is in process to become a PST, there will be tricky aspects in the exam which can help you start doubting your understanding of technical debt vs undone work.
In this article, i am going to define Technical Debt VS Undone Work truly in scrum context and their impacts on transparency. Make sure, you are better equipped with the understanding, before you attempt the exam.
In scrum context, technical debt is the result of conscious or unconscious decision that teams take where they are doing work that is not upto the quality level they like. This will help them in quicker realization of value.
Remember, with even producing the technical debt, you are putting something into production.
Impacts of Technical Debt
- Technical Debt should always be made transparent on the backlog. If not, it can start creating false assumption about the state of product.
- Development teams should try to repay the debt back in upcoming sprints. Accumulating lot of technical debt can slow down the rate by which scrum teams deliver value. For example direct impact on degradation of velocity.
- Even accumulating the technical debt, the scrum teams put something into production.
- The challenge with technical debt is a team may be forced to pay it back at a time when it’s not convenient. Also, the cost of paying it back may be higher than expected. The technical debt can start impacting the forecasting and estimation ability of the development team which in turn impacts empiricism.
Don’t confuse Undone work with technical debt. For example, i have heard teams saying we have some defects for a particular PBI. It’s not a technical debt. It’s typically UNDONE work.
Undone work is work that you can’t put into production. It results in no value realization. That’s a basic difference between technical debt and UNDONE work.
Impacts Of Undone Work
- Undone work can’t be put into production which means that scrum teams can’t demonstrate a working product in sprint review. It impacts the ability of scrum team to receive feedback which will impact empiricism.
- Assumptions made regarding effort of Undone work can be so much that it can invalidate not only the work of current sprint but the work of all previous sprints.
In summary, i always advise my teams not to have any UNDONE work in any sprint.
Hope this article helps you clarify the confusion between technical debt and undone work in the scrum context.
Impacts of technical debt and undone work on transparency are famous areas where you can expect questions in PSM III.
If this article was useful for you, please HIT the LIKE button.