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 / Threat Origin | Notes | Point Value |
|---|---|---|---|
| Communication Risks | |||
| 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 | |||
| Requires agreement on a protocol / data format with another team | |||
| Requires regular meetings | |||
| Requires learning an unfamiliar technology / standard | |||
| Untrained staff involved in the delivery | |||
| Specifications not available | |||
| Reverse-Engineering Required | |||
| - Internal-Model Risk | Involves reconciliation with another data source | ||
| Involves real-time data synchronisation | |||
| 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 | |||
| 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 | |||
| Involves experimentation about best approach | |||
| No prior work exists in this area | |||
| Significant algorithmic innovation is required | |||
| - Lock-In Risk | Ecosystem choice | ||
| Platform choice | |||
| App stores | |||
| Language choice | |||
| Market choice | |||
| Feature Risks | |||
| Requires new interface to be added | |||
| Requires refactoring of existing interfaces | |||
| Deprecates existing functionality | |||
| Requested by multiple stakeholders | |||
| Changes existing functionality | |||
| 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 | ||
| 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 | |||
| 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 | |||
| 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 | |||
| Requires involvement from other members of staff | |||
| Requires hiring-in new specialist skills | |||
| Has dependency on key-persons | |||
| 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 | |||