Sorry, in advance for the longer post...
We have a SaaS product for managing certification and licensure programs. Our product team delivers software in every release that is funded by internal initiatives and by client customization projects from our consulting arm. Since we 1) have a single code base 2) we coordinate around a single release scheduled and 3) mingle is integrated w/ SVN, we run all of this product's activity through a single Mingle project.
We have modeled our sales process as a card tree that has Client -> Project -> SOW -> Story cards, where the story cards eventually get prioritized and put in a sprint in the planning tree. Projects and SOWs each have statuses and properties that can be aggregated, etc - it's awesome!
We haven't quite figured out the most efficient way to organize stories in a SOW. Imagine we're responding to a customer request for some enhancements. For example, they want to track activity based on a couple new properties, like "Subject Matter" and "Delivery Network" and they've asked for some other unrelated enhancements. We plan to sell it all together, so it's all in a single SOW. As I talk to the client, I end up with three lists of stories.
When we go to prioritize the stories, I'd like to group them in a way that facilitates the discussion -- "Let's start with the Subject Matter stories first" and so on. These aren't exactly "features" in the product tree. We're trying to use the SOW card to present the requests in an intuitive way, capture decisions about the sales process and reflect the client's priorities.
In general, we've been hesitant to modify the properties of the Story card, since it's such a core card type, but we will if it's the right thing to do.
There is an analogous problem in the sprint. As cards move through the lanes, QA might have 10 cards 'ready for testing' and 3 are fairly related. How should we give a tip to the tester that he/she could take ownership of all 3 of them and start testing?
Has anyone tried to solve a problem like this?