Use A List Of Major Impact Areas To Think Through New 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. 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.