How to Manage Large Agile Enterprise Programs with Features

Many organizations have trouble communicating effectively between executives, product owners, and developers.

Why?

Because they are trying to decompose high-level epics into granular user stories.

Features are needed to scale, because it’s too difficult to manage large programs with just user stories.

What’s the best way to use Agile features to manage large enterprise programs?

Agile Features

I recently worked with a large mobile telecom where the organization had been breaking epics directly into user stories. They were experiencing issues and didn’t find it effective to go from big, high-level epics to small detailed stories. This is a challenge I see at a lot of organizations and there is a simple solution, features.

Features are needed to scale, because it’s difficult to manage large programs with just user stories. Release planning becomes too detailed if you don’t have a middle tier of features representing what you’re trying to build. Without features you lose the ability to coordinate across teams effectively and are not able to provide enough context about the higher level value and goals. You need features to define the product, coordinate, and plan what you’re going to build at the delivery team level.

It is much more effective to discuss what the development teams will deliver in the future by describing it in high-level features,  particularly for folks at the senior leadership level, senior product owners, and executives. User stories do not resonate with them, because they’re too granular. A senior executive doesn’t want a list of two-hundred user stories that you’re going to deliver in the next release. They don’t have time for all that detail. They want to talk higher level about what key capabilities are going to be delivered in this release, six months or a year down the road.

You apply a lot of the same rules for features that you do for user stories. You deliver features frequently, synchronize your work across teams, and limit your work in progress for features just like you would for user stories.

Tips for Agile Features

There are a few rules that I try to impart when I’m dealing with features. I like to allow features to span iterations, but I generally don’t want features to span releases. By that I mean, if you have a product release six months down the road, you want to make sure that you’ve got all the features you’re going to build within that release and you don’t have a feature that’s partially in one release and partially in another release.

It’s important that your organization doesn’t feel like the product roadmap and features are etched in stone. The features may change based on new challenges that the team has discovered. You may discover that one particular feature is going to take longer than you expected, and so it’s important to review this feature set in a regular cadence with senior leadership, so they know what to expect in the future. Don’t set the false assumption with senior executives that the feature set is fixed and it’s not going to change. This is software, and things always change. Contrary to popular opinion I find executives are pretty amenable to change. They just don’t like surprises.

When you define features, they need to be associated with a particular goal of the system. If the feature does not align to a particular goal you may start having feature creep and orphan features. Your product owner team should be responsible for making sure each feature is aligned with a specific goal. The product owner team should take the big picture that’s being discussed at the portfolio level and decompose those long-term objectives into release-level features. It’s also their responsibility to take those features and help decompose those into user stories. I recommend you do that by defining the product roadmap and conducting roadmap workshops or release planning workshops.

Another important responsibility of your product owner team or core product team is to make sure that dependencies between features are managed. The best way to do that is to make sure there are as little dependencies as possible and to make sure that features are as self-contained as they can be. Ensure features are not dependent on aspects of other features.

Just like user stories, features can be described in what we call the traditional “Three C” format, card, confirmation and conversation. The three C’s help your team gain a shared understanding of the feature. You can confirm your shared understanding of features with acceptance criteria and visual specification. The visual specification can be a use case diagram, sequence diagram, wire-frame diagram or mock user interface. Just provide a visual representation to describe what product capability the feature provides.

Summary

I hope I’ve inspired you to look into whether features would help your organization. If you are using features, I hope you’ve found some value in revisiting the best way to utilize them. If you are not using features, take some time to investigate if there are communication break downs when product owners are breaking their epics into user stories.

What are some tips you have for using user stories?