1. Finish stories that have testing complexities early in the sprint – Asking QA to test and develop an automation for complex stories two days before a sprint ends is not realistic. Smart teams review their commitments to ensure that complex stories can begin work early in the sprint cycle. If you are estimating in story points (which I highly recommend), any story with thirteen or more points should be completed by developers no later than halfway into the sprint.
2. Use system upgrade releases to upgrade infrastructure – Pre-agile, pre-devops, and pre-cloud, most teams doing software development had the rigor of separating out system upgrades from application development releases as part of a release management strategy. Today, even though many agile teams are implementing CI/CD and automated testing, I still recommend this discipline of holding infrastructure (including versions of underlying software components and architecture) fixed during major and minor releases and utilizing system upgrade releases to do upgrades, enhancements, and patches. This discipline is more to protect the major and minor releases from unexpected issues stemming from upgrades.
3. Dedicate 20% of major releases and 60%+ of minor releases to tech debt – Technical debt doesn’t get addressed on its own and teams need guidelines on resolution benchmarks. I’ve recommended 30% as an overall tech debt target and have published a process to manage technical debt in agile. If you are following a major/minor release strategy then setting different benchmarks for major and minor releases is my recommended approach to reduce technical debt.
4. Commit to spikes when testing new technologies – Some teams want to download and use every new library or tool that gets published in Github. Others may have established platforms, but expect new features to work-as-expected. Both may find their agile stories failing or requiring a lot more effort than expected because they didn’t spike to validate their assumptions.
5. Measure the developer onboarding experience and duration – Your architecture, code, and documentation isn’t that good. It just isn’t. So don’t predict that even experienced developers can show up on a team and be productive contributors on day one. Even small dev organizations define an onboarding experience to help new agile team members learn the products, understand customer needs, review the architecture, learn the code base, and test simple code changes. The more advanced organizations use surveys or other tools to measure the onboarding experience and capture a KPI on time-to-productivity.

Just like architecture and standards, agile organizations should develop a playbook on their risk mitigation strategies.