Here’s how this plays out:

The ideal digital tool
I have selected the two (or more) story cards in the view. I right-click one of them and select ‘merge’. Done. The different story texts are viewable from the one story record, the different test cases are visible from the one, if there are any, and if there are no field conflicts, the records merge without prompting. If there are conflicts, I get to see them both, and I get to resolve the conflicts right then. History is preserved.
Usability: Very High Downside: None

The 3×5 card method
I hold the two in my hands. I decide they are really the same story. I grab a stapler and staple them together. Done.
Usability: High Downside: card in back has less visibility

The Excel method
Move the two rows so they are adjacent. Resolve any field conflicts. Copy the story text into the target row. Delete the one that is no longer needed.
Usability: High Downside: can not treat as two different stories as far as role grouping goes. Easy to screw something up.

VersionOne
Add key fields to your view, and make them editable, so you can resolve conflicts in place. Display the Order field so you can re-order items in place. Drag the two so that they are side-by-side in the list of stories. Make sure that you update the important fields in the story that you are going to keep based on the values from the story that you are merging in. Hover over the story you are merging in to display the details. Highlight and copy to the clipboard. Open the story you are merging into. Paste the story text in with the existing story text. Select the Show Tasks/Tests option, and expand the story you are merging in. One by one, drag tasks or tests and drop them on the story you are merging it into. When you are done, delete the obsolete story.
Usability: Medium Downside: tedious, especially if there are tasks and tests to transfer over.

Rally
If you use the new Beta Backlog screen, you can drag the two so they are side-by-side, add fields to the display, modify editable fields to resolve field conflicts, hover over the ID so the details pop up, highlight, copy to clipboard, edit the target story, paste the story text in, and save the changes. To deal with related tasks/tests, you need to make the story that you want to keep a child of the one you are merging. This will push all of the relationships down to the leaf node of the tree. Then, you have to change the parent of the one you want to keep to be something other than the one you are merging with. Otherwise, you have to go into every task, update it, and change its WorkItem to be the one you are keeping, which is very tedious.
Usability: Medium-Low Downside: the technique is either non-intuitive, or extremely tedious.

AgileOnDemand
If the stories are not already in the same epic, you must go to the Planning area (across the top), where you can drag and drop the stories into the necessary epic. However, once there, you can not drag-and-drop them within the epic to make them side-by-side, no matter what view you use. But you can add important columns, then edit them in place to resolve conflicts. Then you must go in to a story (there is no hover-popup) in order to select the story text and copy to the clipboard. You will then have to go BACK into the story to get the Acceptance Criteria, as they are separate fields. That, or you must copy/paste into Notepad (or equivalent). Tasks can be drag-and-dropped from one story to another to re-parent them, but they must be done one at a time. The tool lets you multi-select, but it won’t let you re-parent them in a single action. The tool does not have Tests as a class of task, though you could easily use “Test” as part of the task name. However, since tasks have two different owner fields, one for Development and one for QA, managing the testing effort is not seen as part of the tool’s domain.
Usability: Medium-Low Downside: even more work than the others

Mingle
This tool is a totally generic tool. How you configure it has a lot to do with how it functions. Using the Agile Hybrid template, you switch to the Planning Tree view, and you drag and drop tasks from one story to another. That part is easy. Then, from the All tab, you can add/remove columns. However, it doesn’t look like you can edit them in place. This makes resolving conflicting field values very hard. One thing you CAN do, however, not that it is necessarily recommended, is have a hierarchy that treats User Stories separate from backlog items. Then, you can associate multiple user stories with the same backlog item, without having to modify the text. When you pull up the ‘cards’ that tell the story from one user’s perspective, you can get ONLY the story from that user’s perspective, something you can’t do with any other tool. Cool, but is it worth it?
Usability: Low Downside: ultra-tedious to merge conflicting fields

Usability Comparison Summary on a scale of 1 to 10

Thankfully, this isn’t something you have to do every day. Next, let’s look at something you DO have to do a lot when initially creating your backlog.

Humans are only able to hold so many distinct pieces of information in their head at a time. Past a certain point, the mind naturally starts treating things as bundles, groups of related items, in order to continue working on them. Some people are able to hold these separate items, others are better at transparently grouping things together. But in the quantity of items that are needed for anything but the simplest of projects, every product owner will need to group those user stories together in order to facilitate the creation process.

For example, as I create user stories, I might find or create two that tell the same story, but from a different perspective. Each adds value, and I would want the different perspectives captured and communicated, but ultimately they are the same story. If I were literally using ‘story cards’ as in 3×5 cards on a desk, then in that case I would capture that information by stapling the cards together, so they are treated as one.

As the number of story cards increases, I might start making piles of story cards that are closely related, but they are not quite the same. For example, one story card may represent the basic functionality, while another represents a bit of additional functionality that can be added later which one stakeholder or another might be able to leverage. As more stakeholders weigh in, the pile gets more and more cards in it. Once everybody feels like they have defined what they want, I might give that pile a ‘label’ so I understand what is in it, and then I would paper-clip them all together. From that point forward, I will usually treat that pile as a unit, peeking inside only when I need to.

As the number of story cards continues to grow, more and more of these piles are going to exist. These piles will need some way to organize them. I would look them over, find things they have in common, and start making groupings. Once I have a grouping that seems to me to be ‘complete’ I would use a binder clip to hold them all together, with a ‘summary’ card on top of them all, so I can treat them all as a single element.

In some cases, I may deliberately create ‘groupings’ and then start creating story cards to go into that grouping. But in many cases, I will be creating groupings after-the-fact. And unfortunately, I may undo and re-do my groupings once or twice before I am satisfied with them. I may move individual cards from group to group, or I may move entire groups to other groups.

While creating the cards, I will periodically re-open my groups one by one to inspect them and see if any additional stories come to mind. If not, I close them up again and move on to the next, until I feel like I have a degree of completeness.

Most likely, the grouping that I will use initially will be functional in nature. Related functionality will be grouped together. But sometimes, it helps to look at things from a different perspective. So I will want to see my stories grouped by role, so I can look at all of the stories told from the perspective of a particular stakeholder. In doing so, I may realize that there are stories that I may have missed. Or, I may take that bundle of story cards to that stakeholder to review.

Later, when assigning business value, I may want to re-group them again, according to the type of value that they provide to the business, such as attracting new customers, retaining existing customers, increasing income from existing customers, reducing expenses, limiting legal risk, and so forth. In this case especially, one card may belong to multiple groups. By reviewing the cards in context with other cards that have a similar goal in mind, it will make it easier to get a perspective on relative business value.

Of course, a story is not complete if I have not defined acceptance criteria. So I will need to go through the stories one by one, starting with the ones that provide the most business value, and write the acceptance criteria.

Finally, the sizing of stories can begin.

A good backlog tool will be at least as flexible as the analog that it seeks to emulate. Creating story cards will be quick and easy. Moving them around and grouping them together should be nearly effortless, from a technical standpoint.

Ideally, it will be even better than the analog. I can create as many groupings as I want, and nest them as deeply as I need to, without running out of ways of holding them together. I can move some aside that I’m not actively working on, sort them according to whatever criteria I want, or find a specific story without having to remember which group I put it in.

The Tools

In looking for a backlog management tool, the first thing that I found was that the majority of tools completely ignore the need for grouping. The concept of ‘epics’ and ‘themes’ are absent from a great many of them. While I did see a tool that really impressed me, for a number of reasons, the absence of that one feature meant that I had to eliminate the tool from consideration.

After reviewing dozens of backlog management tools, I managed to narrow the field to four: Rally, VersionOne, Mingle, and AgileOnDemand. Of course, for completeness, I need to consider using Excel, the ‘recommended’ tool from the literature, and actually using stacks of 3×5 cards. The deciding factor is going to have to be, does the tool let me do what I want, the way that I want to do it?

As we move forward in this analysis process, we will take specific scenarios and see how they compare.

Business people and developers must work together daily throughout the project.

The responsibilities of the business owner are to do just-in-time planning, filling in the details in the backlog sufficiently that the team will be able to understand the work that needs to be done in the next sprint. They define what it means for a story to be completed. In addition, they are to serve the informational needs of the team, interfacing with the end users and the subject matter experts.

During the course of development, questions are bound to arise. Given a choice of going one way or another, if it is a technical question, then it is up to the team. But if it is a domain or a business choice, then the Business/Product Owner needs to make that decision. For that reason, the the business owner should expect to be working with the team on a daily basis. They should make themselves available to them, perhaps even co-locating with them. They should be proactive, cultivate a culture of questions and feedback from the team.

An all too common mistake is to have a business owner that shares his time between projects. The problem there is, all of the teams suffer as a result. While the company may be paying one less salary, they are getting less productivity out of 15 or more people. Not a wise trade-off.