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

  1. Next time you are asked to estimate a piece of work, run through the checklist.
  2. Assign a “point value” of your own to any important items. You can use numbers, S-M-L, whatever.
  3. 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.
  4. Consider breaking up risky work into smaller units to isolate the risks individually.
  5. Consider removing unnecessary risk from the project.
  6. 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    

Add Your Star On GitHub to receive an invite to the GitHub Risk-First GitHub team for new article notifications and discussion.

Rob Moffat
Rob Moffat Author of Risk-First Software Development. Developer. Working in the UK.