Skip to main content

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.

AreaConcernNotesPoint Value
Communication Risks
- Channel RiskRequires 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 RiskRequires agreement on a protocol / data format with another team
Requires regular meetings
- Learning-Curve RiskRequires learning an unfamiliar technology / standard
Untrained staff involved in the delivery
- Invisibility RiskSpecifications not available
Reverse-Engineering Required
- Internal-Model RiskInvolves reconciliation with another data source
Involves real-time data synchronisation
- Map-And-Territory RiskUse of metrics
Use of bonuses
Competing targets / KPIs
Coordination RisksTask 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 RiskInvolves 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 RiskInvolves experimentation about best approach
No prior work exists in this area
Significant algorithmic innovation is required
- Boundary RiskEcosystem choice
Platform choice
App stores
Language choice
Market choice
Feature Risks
- Conceptual Integrity RiskRequires new interface to be added
Requires refactoring of existing interfaces
Deprecates existing functionality
Requested by multiple stakeholders
- Regression RiskChanges existing functionality
- Feature-Access RiskInterface Experimentation required
Varied user population
Accessibility requirements
Localisation Requirements
- Implementation RiskDeveloper unfamiliar with the requirements / system
Known corner-cases
Home-grown protocols vs. standards
- Feature-FitSuccess criteria hard to define
Difficult-to-access user base
- Market RiskRapidly 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 RisksGeneral 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 RiskRequires 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 RiskRequires booking time with a 3rd party
Requires specific licenses / approvals
- Funding RiskRequires payment by a customer for completed work
Requires agreement on pricing / budget
- Staff RiskRequires involvement from other members of staff
Requires hiring-in new specialist skills
Has dependency on key-persons
- Red-Queen RiskDependency on rapidly changing/unpublished standards
Dependency on rapidly evolving 3rd party code
- Schedule RiskTask is repetitive
Task takes a long time
Task is unusually tedious
- Reliability RiskHas strict reliability / response time requirements
Has unusual hosting requirements
Unfamiliar hardware involved
- Process RiskUnfamiliar process for releasing
New CI Steps Needed
Unfamiliar approvals required
- Deadline RiskHas components that must be completed during certain time windows (e.g. weekends)
Has components that must be completed before drop-dead dates
Operational RiskRequires new or extra production support
Requires special roll-out
Legal Requirements
Regulatory Requirements