I’ve long had a nagging concern about the grouping of user stories into features (and/or epics, if you work with those). When you’ve got a lot of user stories then grouping them in some way makes sense—without that they’re too difficult to manage. But people tend to think of “feature” as “functional component”, and then when it comes to prioritisation we start facing some problems.
If we prioritise our features—say we place feature A above feature B—then we end up implementing user stories in feature A that are less important than user stories in feature B. If we ignore features then we are back to having an undifferentiated bag of stories.
One useful way through the problem is to prioritise by use cases. We take a very simple scenario and see what needs implementing to deliver it. It will almost certainly cut through many of what we previously called “features”. Then we can take more and more use cases, until eventually our remaining, unimplemented, user stories are much reduced, and prioritisation becomes easier again.
By talking about use cases rather than more traditional “features” we are cutting across our user stories in a different direction, and improving our ability to prioritise.
We used this in our work at Barclays a couple of years ago and it seemed to work quite well.