Interference Checklist
Here is an example "Interference Checklist", which you can use to estimate the risk on your stories / tasks. For an explanation of how this works, check out the previous article On Story Points.
This is just meant to be used as a starting point - feel free to adapt this to the specifics of your own projects and environments.
Some Simple Instructions
- Next time you are asked to estimate a piece of work, run through the checklist.
- Assign a "point value" of your own to any important items. You can use numbers, S-M-L, whatever.
- Total up the points. For a low score you should feel fairly happy about hitting a given end-date for a piece of work. For a high score, you should have low confidence in your estimate.
- Consider breaking up risky work into smaller units to isolate the risks individually.
- Consider removing unnecessary risk from the project.
- After, or during a piece of work, add any new risks you discover to the checklist to remind you about them next time.
Download this in PDF or Numbers format.
| Area | Concern | Notes | Point Value |
|---|---|---|---|
| Communication Risks | |||
| - Channel Risk | Requires input from other team members | ||
| Requires input from other teams | |||
| Requires input from other departments | |||
| Input required, not clear from who, but further up the hierarchy | |||
| - Protocol Risk | Requires agreement on a protocol / data format with another team | ||
| Requires regular meetings | |||
| - Learning-Curve Risk | Requires learning an unfamiliar technology / standard | ||
| Untrained staff involved in the delivery | |||
| - Invisibility Risk | Specifications not available | ||
| Reverse-Engineering Required | |||
| - Internal-Model Risk | Involves reconciliation with another data source | ||
| Involves real-time data synchronisation | |||
| - Map-And-Territory Risk | Use of metrics | ||
| Use of bonuses | |||
| Competing targets / KPIs | |||
| Coordination Risks | Task will require an approval from someone outside the team | ||
| Task requires sign-off from a committee/board | |||
| Requires other tasks to be completed | |||
| Work must be coordinated amongst multiple stakeholders | |||
| Approvals are required from multiple stakeholders | |||
| Different timezones involved | |||
| Data must be synchronised across different machines | |||
| Developers will be required to work together | |||
| Teams are required to work together | |||
| Complexity Risks | |||
| - Codebase Risk | Involves refactoring | ||
| Introduces new languages / DSLs | |||
| Requires adding significant code | |||
| Can’t be easily unit-tested | |||
| Requires manual testing | |||
| Requires deleting significant code | |||
| Creates new repos | |||
| - Dead-End Risk | Involves experimentation about best approach | ||
| No prior work exists in this area | |||
| Significant algorithmic innovation is required | |||
| - Boundary Risk | Ecosystem choice | ||
| Platform choice | |||
| App stores | |||
| Language choice | |||
| Market choice | |||
| Feature Risks | |||
| - Conceptual Integrity Risk | Requires new interface to be added | ||
| Requires refactoring of existing interfaces | |||
| Deprecates existing functionality | |||
| Requested by multiple stakeholders | |||
| - Regression Risk | Changes existing functionality | ||
| - Feature-Access Risk | Interface Experimentation required | ||
| Varied user population | |||
| Accessibility requirements | |||
| Localisation Requirements | |||
| - Implementation Risk | Developer unfamiliar with the requirements / system | ||
| Known corner-cases | |||
| Home-grown protocols vs. standards | |||
| - Feature-Fit | Success criteria hard to define | ||
| Difficult-to-access user base | |||
| - Market Risk | Rapidly changing market | ||
| Market needs are not clear | |||
| Market itself is uncertain | |||
| Product needs to find it’s market | |||
| Agency Risks / | 3rd Party involved | ||
| Trust Risk / | Competitor involvement | ||
| Security Risks | General public involved | ||
| Available on the open internet | |||
| Requires authentication / authorisation schemes | |||
| Requires cryptography | |||
| Involves crowdsourcing | |||
| Involves untrusted data-sources | |||
| Involves multiple processes / threads cooperating | |||
| Involves payments | |||
| Involves security infrastructure: firewalls, proxies, VPN etc. | |||
| Dependency Risks | |||
| - Software Dependency Risk | Requires the introduction of a new dependency | ||
| … which is immature | |||
| … which must be chosen from competing alternatives | |||
| … which is Open-Source | |||
| … which is In-House | |||
| … which is Commercial | |||
| - Scarcity Risk | Requires booking time with a 3rd party | ||
| Requires specific licenses / approvals | |||
| - Funding Risk | Requires payment by a customer for completed work | ||
| Requires agreement on pricing / budget | |||
| - Staff Risk | Requires involvement from other members of staff | ||
| Requires hiring-in new specialist skills | |||
| Has dependency on key-persons | |||
| - Red-Queen Risk | Dependency on rapidly changing/unpublished standards | ||
| Dependency on rapidly evolving 3rd party code | |||
| - Schedule Risk | Task is repetitive | ||
| Task takes a long time | |||
| Task is unusually tedious | |||
| - Reliability Risk | Has strict reliability / response time requirements | ||
| Has unusual hosting requirements | |||
| Unfamiliar hardware involved | |||
| - Process Risk | Unfamiliar process for releasing | ||
| New CI Steps Needed | |||
| Unfamiliar approvals required | |||
| - Deadline Risk | Has components that must be completed during certain time windows (e.g. weekends) | ||
| Has components that must be completed before drop-dead dates | |||
| Operational Risk | Requires new or extra production support | ||
| Requires special roll-out | |||
| Legal Requirements | |||
| Regulatory Requirements | |||