Technical risks are potential dangers, holes, or choices for a given piece of development which will likely cause adverse customer impact and/or will impair future development. Risks are any deviations to standards or good practice where work has been delivered to customers (including any pre-release format).
Technical risks include:
- Over-reliance on unit tests and limited unhappy path testing
- Limited performance / stress testing
- Using non-standard development approaches
- Providing excessive permissions to users and/or resources
- Deviating from established security baselines
Examples:
- APIs do not meet the relevant security standards
Technical Debt (or “Tech Debt”) is the measure of issues which should be resolved.
Note
Tech debt is NOT an absence of desired features / completion of user stories - it is measure of technical deviations.
Left unmanaged and/or unrecorded, Technical Debt can set up vicious cycles within development teams.
- Hard-coded credentials
- Wide Connectivity / Attack Surface
- Non-standard authentication patterns
- Software Version Obsolescence / Failure to Patch
- Non-standard coding language - e.g. VBA
- Failure to implement indexing & server management techniques
- Having excessive indexes which are unused
- Not reviewing and acting on recommended indexes
- Excessive log file growth
- Poor data models
- Building on burning-bridge systems
- Short-term solutions become embedded and re-sold
- Unexpected use-cases and Non-Functional Requirements
- Cloud first, On-Prem
- Public Cloud, Hybrid Cloud
- Use of Database VMs when there is a goal to be serverless
- Lack of houskeeping and data life-cycle management?
Technical Risks should be tracked in work tracking tool (e.g. Jira) and, where possible, linked back to the original User Story / delivery. A framework for assessing these risks is provided below. Anything that is unlikely to be (at least partially) resolved within 12 months should be ACCEPTED as a Risk. If it unpalatable to Accept the risk it becomes technical debt.
Broadly we take a 12 month horizon (for likelihood of an incident) and also for issue resolution.
Initial estimates for technical debt should use fixed values based on expected complexity to resolve:
- 1 hour
- 10 hours
- 100 hours
- 1000 hours etc.
These can be refined later once a plan formed/any blockers have been removed. If unsure, use the next level. It should be a fully-loaded estimate, including development, testing AND deployment.
| Severity \ Likelihood | Low | Medium | High |
|---|---|---|---|
| Low | 1 | 2 | 3 |
| Medium | 2 | 4 | 6 |
| High | 3 | 6 | 9 |
How likely is there to be some form of adverse incident (e.g. MI) related to the technical debt issue in the next 12 months, which would be (partially) mitigated by improving the issue. - Low = Less than 33% probability - Medium = 33% to 66% probability - High = Greater than 66% probability
These are broad ranges, and probabilities will likely be a subjective estimate. Be cautious and take the higher bound of any personal view.
This is a very subjective assessment of the impact of predictable adverse events linked to the technical debt issue. Points to Consider:
- Financial Loss, Reputational Damage (e.g. GDPR Penalties)
- Operational impact on business
- Time to recover, ease of recovery and impact to other services during recovery.
- Extreme scenarios do not need to be considered if they are highly unlikely to occur.
- If there are a number of possible events, consider how many would be likely to occur in a 12-month period -- If only one is likely, score on the most severe likely event -- If a number are likely to occur, score a plausible combination including the most severe likely event
Technical Debt Score is a measure which allows the improvement or worsening of a technical debt position to be measured as a balance. Calculation is simply:
Technical Debt Score = Risk Score x Hours Estimate
This measure is useful as:
- it is a measure of overall business cost comprising risk and time/cost to fix
- mitigation actions which result in a lowered risk score on the technical debt item will reduce this balance, generating a measurable improvement -- i.e. reduction is beneficial - full elimination is not necessary -- technical debt which is both high risk AND complex to fix will have significant scoress and therefore deserve attention
Once added to Technical Debt, an issue can have one of four outcomes:
| Resolution | Description |
|---|---|
| Fixed | The issue has been resolved, with any changes deployed on all jobs in production. (If there are pockets which have not been resolved, create a linked ticket with the reduced impact to remain on backlog). |
| Migrated Away | Issue has been resolved by change in technologies, whether source, target, or tooling |
| Accepted | Product owner has permanently accepted the risk and item will not be worked |
| Not resolved | Still open, or are unable to resolve (i.e. there are other blockers) |