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. 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
- Does this feature make other features obsolete?
In Accept360, I created a page in the requirement template with the Impact Area list. 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’s sometimes difficult to make yourself go through this list, but particularly for bigger features, it’s a valuable exercise.