Feature-based Benefits

Imagine you have several projects, which you’re trying to get a delivery team to deliver. Those projects are really important and there is a lot to be delivered, but they are also competing with each other for scarce resources.

Typically, in a traditional development shop, the first project is delivered to completion. The team are then freed up and put onto the second project until that project is delivered to completion, and so on.

You’d imagine the first project has some features being building that are less valuable and more time consuming to deliver than the most urgent, most important and most-valuable features in the second project.

This means:

• You’re prioritising the lower value features in the first project for…
• The higher value features in the second project

This is clearly nonsensical.

If you can do a feature-based approach, where you define a feature in terms of what the end-user will get (including all the dependencies required for that feature), then you can:

• Assess the value of each feature against each other feature
• Assess the cost (including the building of the dependencies)

Evaluate this to understand the highest value for the lowest cost and build that first.

You might then find that the second project and third project have features that you want to start using in production before you build the features that are lower value in the first project.

If you take a feature-based approach to define what the project chunks are then you will be in a stronger position to deliver the most valuable features first, irrespective of which project they’ve been categorised into.