An “Impact Areas” list helps you develop higher quality features
I often use a list of product “Impact Areas” to assess the impact of a new feature on the rest of the product.
As I’m developing a requirement, I go through the list of impact areas and note down whether this feature requires a change in that area. If not, I mark it as “N/A.” If there is an impact, I note it down.
Impact Areas example
When I was managing Accept360, some of the impact areas were:
- Table views and filters. (We had user-definable filters for finding entities, so if there was a new property, you’d have to make sure the filters supported it and the result list could display it in a useful way)
- The release or sprint backlog. The feature might need a new column, or a new business rule for calculating a column value
- History log entries
- Default values or settings
- Notifications required for this feature
- The terminology and lexicon for the feature
- Are there best practices for using the new feature? What are they?
- Import or export
- Permissions required, especially if there is a new role needed for the feature.
- Does this feature make other features obsolete?
In Accept360, I created a page in the requirement template with the Impact Area list. (Accept 360 supported multiple pages in a requirement, so this was easy.)
It was easy to go through the list and enter the notes.
Today, using Confluence, I typically use a child page to capture the impact areas.
It only works if you use it
It’s sometimes difficult to make yourself go through this list of impact areas, but particularly for bigger features, it’s a valuable exercise.
For any particular feature many of the Impact areas may be not applicable – so you just enter “N/A” for that area.