From 2cd21a6e482145c265e3710fb97032c3311a6a86 Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 09:15:12 +0100 Subject: [PATCH 01/12] Update TechnicalDebtMonitoring.md --- .../TechnicalDebt/TechnicalDebtMonitoring.md | 56 +++++++++---------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md index 9befeba0..4538d7d4 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md @@ -12,34 +12,34 @@ ## Work item fields -* A **Technical debt** work item type **MUST** be created in target project. - * Add new Details section with the following fields (use existing field, do not create a new field): - * Primary Product or Service - * there may be several interconnecting products but which is the main one, if needed, create a separate TD item for each product if they would be addressed separately. - * Technical priority - * TD1 - High business/technical value, high risk debt that needs to be paid off ASAP (a Security tag should automatically be considered for a TD1 prioritisation). - * TD2 - High business/technical value (cost reduction, blocker removing, maintainability improvement), lower risk, a change that should be worked on when time/opportunity permits and is not something that can be accepted or supported long term. - * TD3 - Tech debt that has been accepted as a risk but through paying off would add value through improving usability, maintainability, reliability or performance. - * TD4 - Accepted risk from the business, safe to leave until service reaches end of life. Worth tracking in case developers are working in the area and can complete as quick wins. - * Technical debt type - * Architectural – Tightly coupled systems (lots of criss-crossed dependencies), * restrictive to extension or automation - * Code – Low quality code or ineffective patterns - * Knowledge – lack of documentation or inaccessible documentation - * Automation – Lack of automated tasks forcing manual intervention (Testing, deployments, * backup/restore) - * Testing – Unknown or unrecorded test scenarios, lack of test coverage - * Maintenance – Out-of-support products, usually leading to security vulnerabilities - * Process - inefficient or wasteful process steps, this could be related to practice or * tooling - * Security - Known and exploitable vulnerabilities - * Technical debt impact - * Increased time to deliver - * Unplanned work - * Inaccurate planning - * Disengaged Development teams - * Longer times to recover - * Instability - * Security Concerns - * Add a new section called Status - * Add field for Scheduled Release +- A **Technical debt** work item type **MUST** be created in target project. + - Add new Details section with the following fields (use existing field, do not create a new field): + - Primary Product or Service + - there may be several interconnecting products but which is the main one, if needed, create a separate TD item for each product if they would be addressed separately. + - Technical priority + - TD1 - High business/technical value, high risk debt that needs to be paid off ASAP (a Security tag should automatically be considered for a TD1 prioritisation). + - TD2 - High business/technical value (cost reduction, blocker removing, maintainability improvement), lower risk, a change that should be worked on when time/opportunity permits and is not something that can be accepted or supported long term. + - TD3 - Tech debt that has been accepted as a risk but through paying off would add value through improving usability, maintainability, reliability or performance. + - TD4 - Accepted risk from the business, safe to leave until service reaches end of life. Worth tracking in case developers are working in the area and can complete as quick wins. + - Technical debt type + - Architectural – Tightly coupled systems (lots of criss-crossed dependencies), - restrictive to extension or automation + - Code – Low quality code or ineffective patterns + - Knowledge – lack of documentation or inaccessible documentation + - Automation – Lack of automated tasks forcing manual intervention (Testing, deployments, - backup/restore) + - Testing – Unknown or unrecorded test scenarios, lack of test coverage + - Maintenance – Out-of-support products, usually leading to security vulnerabilities + - Process - inefficient or wasteful process steps, this could be related to practice or - tooling + - Security - Known and exploitable vulnerabilities + - Technical debt impact + - Increased time to deliver + - Unplanned work + - Inaccurate planning + - Disengaged Development teams + - Longer times to recover + - Instability + - Security Concerns + - Add a new section called Status + - Add field for Scheduled Release ## Using `Technical debt` work items From 6630bcae23d5b18a16baaecfb05def83b20d13eb Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 09:16:52 +0100 Subject: [PATCH 02/12] Update TechnicalDebtPolicy.md --- .../TechnicalDebt/TechnicalDebtPolicy.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md index 91b43d5c..ecf46ef1 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md @@ -18,26 +18,26 @@ Each product **MUST** maintain a register of technical debt within its Azure Dev This should include all types of technical debt, i.e.: -* Architectural – Tightly coupled systems (lots of criss-crossed dependencies), restrictive to extension or automation -* Code – Low quality code or ineffective patterns -* Knowledge – lack of documentation or inaccessible documentation -* Automation – Lack of automated tasks forcing manual intervention (Testing, deployments, backup/restore) -* Testing – Unknown or unrecorded test scenarios, lack of test coverage -* Maintenance – Out-of-support products, usually leading to security vulnerabilities -* Process - inefficient or wasteful process steps, this could be related to practice or tooling -* Security - Known and exploitable vulnerabilities +- Architectural – Tightly coupled systems (lots of criss-crossed dependencies), restrictive to extension or automation +- Code – Low quality code or ineffective patterns +- Knowledge – lack of documentation or inaccessible documentation +- Automation – Lack of automated tasks forcing manual intervention (Testing, deployments, backup/restore) +- Testing – Unknown or unrecorded test scenarios, lack of test coverage +- Maintenance – Out-of-support products, usually leading to security vulnerabilities +- Process - inefficient or wasteful process steps, this could be related to practice or tooling +- Security - Known and exploitable vulnerabilities ## Technial Debt Impact Technical debt impacts various aspects of an application's life cycle, this is often dictated by the type of technical debt but common impacts you can expect from outstanding technical debt are: -* Increased time to deliver -* Unplanned work -* Inaccurate planning -* Disengaged Development teams -* Longer times to recover -* Instability -* Security Concerns +- Increased time to deliver +- Unplanned work +- Inaccurate planning +- Disengaged Development teams +- Longer times to recover +- Instability +- Security Concerns --- @@ -57,14 +57,14 @@ When raising technical debt, please add the following information to the Technic The description of the Technical Debt item must include the following as a minimum: -* The repository the Technical Debt lives within (a link to the repo would be good but the name would suffice) -* Description of the issue in as much detail as you can provide, including class/file names if this can be included -* A proposed solution or ideas for a fix ** -* Cost/Benefit and risk of the Technical Debt item, simply as a "why should this be fixed?/How long would it take?" +- The repository the Technical Debt lives within (a link to the repo would be good but the name would suffice) +- Description of the issue in as much detail as you can provide, including class/file names if this can be included +- A proposed solution or ideas for a fix ** +- Cost/Benefit and risk of the Technical Debt item, simply as a "why should this be fixed?/How long would it take?" ### Strategy -* A **Technical debt** work item type **MUST** be created in target project. Using queries and dashboads it is then possible to monitor Technical Debt. +- A **Technical debt** work item type **MUST** be created in target project. Using queries and dashboads it is then possible to monitor Technical Debt. ![Example Tech Debt work item](./Example_TD_V4.PNG) @@ -118,4 +118,4 @@ Each team should have its own set of queries and a dashboard. These will be copi ## Points of Contact -* Policy Owner - Principal Support Developer +- Policy Owner - Principal Support Developer From a31fa431a7fa608f1091af99706390dfc523d812 Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 09:37:32 +0100 Subject: [PATCH 03/12] Update TechnicalDebtPolicy.md --- .../TechnicalDebt/TechnicalDebtPolicy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md index ecf46ef1..537d72c5 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md @@ -104,9 +104,9 @@ Defects (also known as bugs) are only considered technical debt if the decision ## Additional Reading -- https://martinfowler.com/bliki/TechnicalDebt.html -- https://martinfowler.com/bliki/EstimatedInterest.html -- https://martinfowler.com/bliki/TechnicalDebtQuadrant.html +* https://martinfowler.com/bliki/TechnicalDebt.html +* https://martinfowler.com/bliki/EstimatedInterest.html +* https://martinfowler.com/bliki/TechnicalDebtQuadrant.html ## Legacy Technical Debt Tracking From 647cc65aa05043fda9bf836e6cc9317eee885a9f Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 09:39:54 +0100 Subject: [PATCH 04/12] Update TechnicalDebtPolicy.md --- .../TechnicalDebt/TechnicalDebtPolicy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md index 537d72c5..ecf46ef1 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md @@ -104,9 +104,9 @@ Defects (also known as bugs) are only considered technical debt if the decision ## Additional Reading -* https://martinfowler.com/bliki/TechnicalDebt.html -* https://martinfowler.com/bliki/EstimatedInterest.html -* https://martinfowler.com/bliki/TechnicalDebtQuadrant.html +- https://martinfowler.com/bliki/TechnicalDebt.html +- https://martinfowler.com/bliki/EstimatedInterest.html +- https://martinfowler.com/bliki/TechnicalDebtQuadrant.html ## Legacy Technical Debt Tracking From a82754027756b8767cb8a51c4ff1a369cdcfd848 Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 10:24:26 +0100 Subject: [PATCH 05/12] Update TechnicalDebtPolicy.md --- .../TechnicalDebt/TechnicalDebtPolicy.md | 40 +++++++++---------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md index ecf46ef1..d37b5975 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md @@ -1,12 +1,12 @@ # Technical Debt Policy -All UKHO employees engaged with digital product development should develop a basic understanding of technical debt, how it's generated, its impacts on the business and how it can be paid off. +All UKHO employees engaged with digital product development should develop a basic understanding of Technical Debt, how it's generated, its impacts on the business and how it can be paid off. -All individuals who identify technical debt should record it as per the following strategy. Where the individual cannot, the information should be passed to the relevant team, product manager or service owner to be raised. +All individuals who identify Technical Debt should record it as per the following strategy. Where the individual cannot, the information should be passed to the relevant team, product manager or service owner to be raised. ## Objective -To provide the UKHO with a detailed and expansive data set about technical debt across the organisation, enabling greater business intelligence at all levels of the organisation for more informed and effective decision making. +To provide the UKHO with a detailed and expansive data set about Technical Debt across the organisation, enabling greater business intelligence at all levels of the organisation for more informed and effective decision making. ## Technical Debt Definition @@ -14,9 +14,9 @@ Deficiencies in internal quality or capability that make a product/service/appli ## Technical Debt Types -Each product **MUST** maintain a register of technical debt within its Azure DevOps project. +Each product **MUST** maintain a register of Technical Debt within its Azure DevOps project. -This should include all types of technical debt, i.e.: +This should include all types of Technical Debt, i.e.: - Architectural – Tightly coupled systems (lots of criss-crossed dependencies), restrictive to extension or automation - Code – Low quality code or ineffective patterns @@ -29,7 +29,7 @@ This should include all types of technical debt, i.e.: ## Technial Debt Impact -Technical debt impacts various aspects of an application's life cycle, this is often dictated by the type of technical debt but common impacts you can expect from outstanding technical debt are: +Technical Debt impacts various aspects of an application's life cycle, this is often dictated by the type of Technical Debt but common impacts you can expect from outstanding Technical Debt are: - Increased time to deliver - Unplanned work @@ -43,11 +43,11 @@ Technical debt impacts various aspects of an application's life cycle, this is o ## Raising Technical Debt -Technical debt identified in the current sprint but not being resolved as part of present work **MUST** be raised as a `Technical debt` work item type in the relevant area of Azure DevOps. The relevant location is based on whether the technical debt is related to a product or a team. +Technical Debt identified in the current sprint but not being resolved as part of present work **MUST** be raised as a `Technical Debt` work item type in the relevant area of Azure DevOps. The relevant location is based on whether the Technical Debt is related to a product or a team. -Ideally even if technical debt is going to be resolved immediately raising it is good for understanding its impact on UKHO work and identifying that technical debt was discovered. +Ideally even if Technical Debt is going to be resolved immediately raising it is good for understanding its impact on UKHO work and identifying that Technical Debt was discovered. -When raising technical debt, please add the following information to the Technical Debt work item: +When raising Technical Debt, please add the following information to the Technical Debt work item: ### Title @@ -64,7 +64,7 @@ The description of the Technical Debt item must include the following as a minim ### Strategy -- A **Technical debt** work item type **MUST** be created in target project. Using queries and dashboads it is then possible to monitor Technical Debt. +- A **Technical Debt** work item type **MUST** be created in target project. Using queries and dashboads it is then possible to monitor Technical Debt. ![Example Tech Debt work item](./Example_TD_V4.PNG) @@ -74,33 +74,33 @@ The description of the Technical Debt item must include the following as a minim ### How this meshes with RAID -A technical debt work item should be created, even if the team is not planning on addressing the technical debt within the current sprint. We advise that teams carrying out RAID analysis and create technical debt work items in addition to this analysis. Consider that some technical debt items have been long lived in the past this will help support or future development teams consider the technical debt for future resolution and when planning. +A Technical Debt work item should be created, even if the team is not planning on addressing the Technical Debt within the current sprint. We advise that teams carrying out RAID analysis and create Technical Debt work items in addition to this analysis. Consider that some Technical Debt items have been long lived in the past this will help support or future development teams consider the Technical Debt for future resolution and when planning. ## Refining Technical Debt -If the technical debt item doesn't meet any of the above it should be considered as debt with little or no value to resolution and considered for removal from the backlog. +If the Technical Debt item doesn't meet any of the above it should be considered as debt with little or no value to resolution and considered for removal from the backlog. If during refinement an imminent issue is discovered (e.g. old Technical Debt, with high risk, which is time sensitive, but has not been addressed) this should be refined and flagged to a senior Solution Architect, Product Manager and relevant Delivery Manager. ## Technical Debt Tracking/Monitoring -There is automated near-realtime monitoring of technical debt available for all projects within the UKHydro Azure DevOps tenant. This is made available by the DDC technical debt Prometheus exporter and relies on accurately tracked technical debt PBIs. For information on this exporter and the technology used please refer to the [technical debt monitoring](../TechnicalDebt/TechnicalDebtMonitoring.md) document. +There is automated near-realtime monitoring of Technical Debt available for all projects within the UKHydro Azure DevOps tenant. This is made available by the DDC Technical Debt Prometheus exporter and relies on accurately tracked Technical Debt PBIs. For information on this exporter and the technology used please refer to the [Technical Debt monitoring](../TechnicalDebt/TechnicalDebtMonitoring.md) document. ## FAQ -**When is a defect (bug) technical debt?** -Defects (also known as bugs) are only considered technical debt if the decision has been made to accept or otherwise leave the defect unresolved. In this case the defect should be marked as technical debt following the provided guidance. If the defect is something intended to be fixed within current or next sprint, then do not mark it as technical debt. +**When is a defect (bug) Technical Debt?** +Defects (also known as bugs) are only considered Technical Debt if the decision has been made to accept or otherwise leave the defect unresolved. In this case the defect should be marked as Technical Debt following the provided guidance. If the defect is something intended to be fixed within current or next sprint, then do not mark it as Technical Debt. -**How do I balance technical debt?** +**How do I balance Technical Debt?** ->‘Technical debt’ is any compromise you make on quality to develop something quickly in the short-term. The extra effort (or ‘interest’) required to improve what you’ve built is something you’ll have to make (or ‘pay back’) in future. +>‘Technical Debt’ is any compromise you make on quality to develop something quickly in the short-term. The extra effort (or ‘interest’) required to improve what you’ve built is something you’ll have to make (or ‘pay back’) in future. > ->As your technical debt grows, your code will become more difficult to work with. This means adding new features will get harder, take longer and introduce more bugs. +>As your Technical Debt grows, your code will become more difficult to work with. This means adding new features will get harder, take longer and introduce more bugs. > ->If you decide it’s necessary to compromise on quality so you can deliver something quickly, your team needs to understand the implications of taking on technical debt. You **MUST** record technical debt even if you don't plan on resolving it. You **should** also agree a plan for keeping it under control. +>If you decide it’s necessary to compromise on quality so you can deliver something quickly, your team needs to understand the implications of taking on Technical Debt. You **MUST** record Technical Debt even if you don't plan on resolving it. You **should** also agree a plan for keeping it under control. > ->Learn one of the ways [GOV.UK managed technical debt](https://insidegovuk.blog.gov.uk/2013/12/10/paying-down-technical-debt-in-the-departments-and-policy-publishing-platform/). +>Learn one of the ways [GOV.UK managed Technical Debt](https://insidegovuk.blog.gov.uk/2013/12/10/paying-down-technical-debt-in-the-departments-and-policy-publishing-platform/). ## Additional Reading From 7495aa7408d4e1d8a2dfd476ed8a525bbe64b520 Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 10:25:12 +0100 Subject: [PATCH 06/12] Update TechnicalDebtMonitoring.md --- .../TechnicalDebt/TechnicalDebtMonitoring.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md index 4538d7d4..3d0da1d6 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md @@ -2,9 +2,9 @@ ## Pre-requisites -- Each project will need a `Technical debt` work item type in their process. +- Each project will need a `Technical Debt` work item type in their process. - This has to be added by a process editor. - - if you are using the default **DGf** template then the project will have a Technical debt type already. + - if you are using the default **DGf** template then the project will have a Technical Debt type already. - Each project will need a "Technical Debt" dash board. - An aggregation of all the "Technical Debt" will be visible on a central dashboard. @@ -12,7 +12,7 @@ ## Work item fields -- A **Technical debt** work item type **MUST** be created in target project. +- A **Technical Debt** work item type **MUST** be created in target project. - Add new Details section with the following fields (use existing field, do not create a new field): - Primary Product or Service - there may be several interconnecting products but which is the main one, if needed, create a separate TD item for each product if they would be addressed separately. @@ -21,7 +21,7 @@ - TD2 - High business/technical value (cost reduction, blocker removing, maintainability improvement), lower risk, a change that should be worked on when time/opportunity permits and is not something that can be accepted or supported long term. - TD3 - Tech debt that has been accepted as a risk but through paying off would add value through improving usability, maintainability, reliability or performance. - TD4 - Accepted risk from the business, safe to leave until service reaches end of life. Worth tracking in case developers are working in the area and can complete as quick wins. - - Technical debt type + - Technical Debt type - Architectural – Tightly coupled systems (lots of criss-crossed dependencies), - restrictive to extension or automation - Code – Low quality code or ineffective patterns - Knowledge – lack of documentation or inaccessible documentation @@ -30,7 +30,7 @@ - Maintenance – Out-of-support products, usually leading to security vulnerabilities - Process - inefficient or wasteful process steps, this could be related to practice or - tooling - Security - Known and exploitable vulnerabilities - - Technical debt impact + - Technical Debt impact - Increased time to deliver - Unplanned work - Inaccurate planning @@ -41,10 +41,10 @@ - Add a new section called Status - Add field for Scheduled Release -## Using `Technical debt` work items +## Using `Technical Debt` work items Once created the work item can be added to the team boards as part of the process backlog level, to allow tracking at the "Requirements backlog" level or as a separate backlog level, similar to features and epics. -The Technical debt portfolio backlog will need to be added to each team view as needed. +The Technical Debt portfolio backlog will need to be added to each team view as needed. ![Portfolio Technical Debt](./Porfolio_TD_V1.png) From 660c5630c5d86ba93be84a90bec31c8fe2c3bd00 Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 13:20:48 +0100 Subject: [PATCH 07/12] Update TechnicalDebtPolicy.md --- .../TechnicalDebt/TechnicalDebtPolicy.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md index d37b5975..7ba91ddf 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md @@ -82,7 +82,6 @@ If the Technical Debt item doesn't meet any of the above it should be considered If during refinement an imminent issue is discovered (e.g. old Technical Debt, with high risk, which is time sensitive, but has not been addressed) this should be refined and flagged to a senior Solution Architect, Product Manager and relevant Delivery Manager. - ## Technical Debt Tracking/Monitoring There is automated near-realtime monitoring of Technical Debt available for all projects within the UKHydro Azure DevOps tenant. This is made available by the DDC Technical Debt Prometheus exporter and relies on accurately tracked Technical Debt PBIs. For information on this exporter and the technology used please refer to the [Technical Debt monitoring](../TechnicalDebt/TechnicalDebtMonitoring.md) document. @@ -104,9 +103,9 @@ Defects (also known as bugs) are only considered Technical Debt if the decision ## Additional Reading -- https://martinfowler.com/bliki/TechnicalDebt.html -- https://martinfowler.com/bliki/EstimatedInterest.html -- https://martinfowler.com/bliki/TechnicalDebtQuadrant.html +- [https://martinfowler.com/bliki/TechnicalDebt.html] +- [https://martinfowler.com/bliki/EstimatedInterest.html] +- [https://martinfowler.com/bliki/TechnicalDebtQuadrant.html] ## Legacy Technical Debt Tracking From 2a8090b551711b51a3f7fd20e2916682542934eb Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 13:23:55 +0100 Subject: [PATCH 08/12] Update TechnicalDebtMonitoring.md --- .../TechnicalDebt/TechnicalDebtMonitoring.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md index 3d0da1d6..2979c8b1 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md @@ -3,8 +3,8 @@ ## Pre-requisites - Each project will need a `Technical Debt` work item type in their process. - - This has to be added by a process editor. - - if you are using the default **DGf** template then the project will have a Technical Debt type already. + - This has to be added by a process editor. + - if you are using the default **DGf** template then the project will have a Technical Debt type already. - Each project will need a "Technical Debt" dash board. - An aggregation of all the "Technical Debt" will be visible on a central dashboard. @@ -12,7 +12,7 @@ ## Work item fields -- A **Technical Debt** work item type **MUST** be created in target project. +- A **Technical Debt** work item type **MUST** be created in target project. - Add new Details section with the following fields (use existing field, do not create a new field): - Primary Product or Service - there may be several interconnecting products but which is the main one, if needed, create a separate TD item for each product if they would be addressed separately. From 5ed0c807d00e4ac0d862158623562e30bba7fba2 Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 13:24:39 +0100 Subject: [PATCH 09/12] Update software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md Co-authored-by: Eleri Valiant --- .../TechnicalDebt/TechnicalDebtPolicy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md index 7ba91ddf..a3746bc1 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md @@ -27,7 +27,7 @@ This should include all types of Technical Debt, i.e.: - Process - inefficient or wasteful process steps, this could be related to practice or tooling - Security - Known and exploitable vulnerabilities -## Technial Debt Impact +## Technical Debt Impact Technical Debt impacts various aspects of an application's life cycle, this is often dictated by the type of Technical Debt but common impacts you can expect from outstanding Technical Debt are: From 597f53742e59d9c0930e5cbb825fb7bd91ec937f Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 13:26:02 +0100 Subject: [PATCH 10/12] Update TechnicalDebtPolicy.md --- .../TechnicalDebt/TechnicalDebtPolicy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md index a3746bc1..41904929 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtPolicy.md @@ -64,7 +64,7 @@ The description of the Technical Debt item must include the following as a minim ### Strategy -- A **Technical Debt** work item type **MUST** be created in target project. Using queries and dashboads it is then possible to monitor Technical Debt. +- A **Technical Debt** work item type **MUST** be created in target project. Using queries and dashboards it is then possible to monitor Technical Debt. ![Example Tech Debt work item](./Example_TD_V4.PNG) From d30c552a266d6f4b5b48ceb0e3908cb87e2c93ce Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 13:28:45 +0100 Subject: [PATCH 11/12] Update TechnicalDebtMonitoring.md --- .../TechnicalDebt/TechnicalDebtMonitoring.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md index 2979c8b1..f7157474 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md @@ -22,13 +22,13 @@ - TD3 - Tech debt that has been accepted as a risk but through paying off would add value through improving usability, maintainability, reliability or performance. - TD4 - Accepted risk from the business, safe to leave until service reaches end of life. Worth tracking in case developers are working in the area and can complete as quick wins. - Technical Debt type - - Architectural – Tightly coupled systems (lots of criss-crossed dependencies), - restrictive to extension or automation + - Architectural – Tightly coupled systems (lots of criss-crossed dependencies), restrictive to extension or automation - Code – Low quality code or ineffective patterns - Knowledge – lack of documentation or inaccessible documentation - - Automation – Lack of automated tasks forcing manual intervention (Testing, deployments, - backup/restore) + - Automation – Lack of automated tasks forcing manual intervention (Testing, deployments, backup/restore) - Testing – Unknown or unrecorded test scenarios, lack of test coverage - Maintenance – Out-of-support products, usually leading to security vulnerabilities - - Process - inefficient or wasteful process steps, this could be related to practice or - tooling + - Process - inefficient or wasteful process steps, this could be related to practice or tooling - Security - Known and exploitable vulnerabilities - Technical Debt impact - Increased time to deliver From 8f7d981d470515b32e8dd38dd3365c2bafba4c58 Mon Sep 17 00:00:00 2001 From: Luke Duddridge Date: Wed, 4 Jun 2025 13:29:38 +0100 Subject: [PATCH 12/12] Update TechnicalDebtMonitoring.md --- .../TechnicalDebt/TechnicalDebtMonitoring.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md index f7157474..48c752e5 100644 --- a/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md +++ b/software-engineering-policies/TechnicalDebt/TechnicalDebtMonitoring.md @@ -22,12 +22,12 @@ - TD3 - Tech debt that has been accepted as a risk but through paying off would add value through improving usability, maintainability, reliability or performance. - TD4 - Accepted risk from the business, safe to leave until service reaches end of life. Worth tracking in case developers are working in the area and can complete as quick wins. - Technical Debt type - - Architectural – Tightly coupled systems (lots of criss-crossed dependencies), restrictive to extension or automation - - Code – Low quality code or ineffective patterns - - Knowledge – lack of documentation or inaccessible documentation - - Automation – Lack of automated tasks forcing manual intervention (Testing, deployments, backup/restore) - - Testing – Unknown or unrecorded test scenarios, lack of test coverage - - Maintenance – Out-of-support products, usually leading to security vulnerabilities + - Architectural - Tightly coupled systems (lots of criss-crossed dependencies), restrictive to extension or automation + - Code - Low quality code or ineffective patterns + - Knowledge - lack of documentation or inaccessible documentation + - Automation - Lack of automated tasks forcing manual intervention (Testing, deployments, backup/restore) + - Testing - Unknown or unrecorded test scenarios, lack of test coverage + - Maintenance - Out-of-support products, usually leading to security vulnerabilities - Process - inefficient or wasteful process steps, this could be related to practice or tooling - Security - Known and exploitable vulnerabilities - Technical Debt impact