7. Decompose each capability into a set of features to be concurrently developed

It is possible to decompose the work further, by dividing each capability into a set of smaller features. For example, the AI system might be separated into features for giving certain kinds of financial advice. However, developing AI systems is often such that to improve the system one must make changes that affect all of the existing features. It therefore might not be possible to decompose the AI work definitively: instead, it might be better to treat it as a series of prototypes, each improving on one or more features, but never declaring any feature done until all the features are done. Progress is measured by overall improvement.

Remember that the goal is to demonstrate a capability – not to complete features.

On the other hand, it might be that financial advice can be partitioned into different categories, and each category could be defined as a feature. Those features could be worked on separately to some extent. Each could be demonstrated. However, if they share the same underlying model, it is always possible that improving one feature might impact another. Business stakeholders would have to be aware of that.

For the other capabilities, one can divide those up more easily, because the work is inherently a little more deterministic. For example, the Web service feature could implement a portion of the service’s API, and then another feature could implement the remaining portion of the API.

Similarly, the Web and mobile apps can be divided up into discrete features for enabling someone to select the financial advice function, select the chosen financial goals, display the results obtained from the Web service, save the results, choose other goals, obtain and save those results, compare them, etc. These features can be defined separately and added to a work backlog and done in the sequence that the developers feel is most appropriate. Each Web app and mobile app feature is demonstrable to business and technical stakeholders, by “mocking” the Web service.

Stay Focused on the Capability

IMPORTANT - don’t lose focus on the capability: that is the goal! The features are not goals.

Tip from SpaceX: tag each technical requirement with the source or person who stated the requirement. That way, if the requirement becomes troublesome, it is easy to find out if it is still needed. Always be ready to ask “do we still need that feature” if it seems that the capability could be met well without the feature. Fewer features is better.

Tracking Work

Tools that track completion of “Agile stories” are generally pretty effective for managing work. However, we remind you that one should not equate completing a story with progress: progress only occurs when a capability has been created or improved. That should be reflected in metrics: each capability should have one or more metrics that reveals the capability’s efficacy. However, a list of the stories that are planned for the purpose of creating or improving a capability is very helpful for tracking the work. Tracking those tells you if you are going somewhere, even if they don’t tell you if you are going somewhere useful.

Also, while you might decompose a capability into a set of stories, implementing those stories does not mean that you achieved the capability: they do not “roll up”. We want to repeat that: a set of features do not “roll up” into a capability. One feature can undo the usefulness of another feature! And a set of features proves nothing.

A capability is only achieved when its metrics prove that it has. For example, just because you completed some stories to improve the performance of an engine does not mean that the engine now has the desired performance. The only way to tell is to test the engine and measure its actual performance.

Thus, a list of features is not a full list of the work to be done: it is only your current opinion about what is outstanding.

It is very common that a capability and even a feature requires that multiple teams coordinate to complete the capability or feature. See the article Dependency Management.

 

Step 6 <—

—> Step 8