The ideal tool would allow the user to set a ‘ranking context’. This would be a way of preserving different sets of rankings for different reasons. By default, the tool would come with ranking contexts for Business Value, Technical Risk, Story Size, and Priority. It should also allow the user to create their own custom ranking contexts, so that the users can utilize this metaphor for whatever they like, without having to compromise.

Another thing I would like to see, in addition to having multiple ranking contexts, is the ability to allow one ranking context to be the starting point for another. For example, in the Priority context, if an absolute priority between two stories has not been determined, then it could default to the ranking defined by the Business Value context. If that context does not define the relative priority, then look at Technical risk, favoring the more risky items. And finally, in the absence of a difference in risk, opt for the smaller stories first. All this should be readily configurable.

Of course, the purpose of these ranking contexts is to augment or replace having to provide an absolute ranking value. So, one could tie the context to a numeric field. As one drags stories up and down in the list, the value changes. Or, one can change the value directly, and anchor the ranking to a particular value, allowing it to jump to the approximately correct position within the list. This position is then able to be refined by dragging, which in turn alters the values of the stories involved. This would best serve those who don’t use Planning Poker or the Business Value Game, but could easily be used in conjunction to serve as a kind of sanity check on the values that are coming out of the estimating.

What I would also like to see is for related items (groupings) to be ranked as well, and for those rankings to influence the relative ranking of the items they contain. So, for example, if I rank one feature group higher than another, then the stories within that group get a slight boost so that the average ranking of the one group is higher than the average of the other group. Likewise, if I rank one Epic or Theme higher than another, again the stories in that epic get a boost compared to the others. I could also consider a particular role above others, and a particular business proposition above others. This, alone, might do well to align the relative ranking of stories without having ever adjusted a single story up or down.

Another thing I would love to see is for there to be calculated fields that represent ratios between some of these fields that are set by ranking. So, for example, if a story has both a Business Value and a Technical Risk value, then a calculated field would estimate the risk/reward ratio. If it has both Business Value and Size, then a Return on Investment ratio is calculated. I would even calculate a Risk/Size ratio, and perhaps even an overall weighted value that takes all three into account to give the product owner a suggested priority starting point.

Of course, this all sounds really complicated. But it doesn’t have to be. A simple configuration combined with a simple but powerful user interface, and the tool can help guide even a novice product owner towards delivering maximum value with a minimum of cost.

It is important that you be able to associate more than one value proposition to a story. What attracts new customers may also encourage existing customers to upgrade their service. In that regard, those tools that do not facilitate the use of Tags, multiple values in a single field, or many-to-many relationships, are at a strong disadvantage when it comes to being able to implement this feature.

From a technical standpoint, implementing this behavior in the various tools is possible in roughly the same way as Role based grouping. You can use Tags, where tags are offered, or you can define a field/property with a set list of values. Their respective usability is the same as that from the previous segment on grouping by Role.

One notable difference is that the user interface of the Ideal Digital Tool can’t cheat and extract it from the user story text, you have to set it yourself. This may require a more sophisticated user interface, though what works for this should work equally well for managing Role assignments.

Usability Comparison Summary on a scale of 1 to 10

Hopefully, the above makes the case adequately enough: It would add value to the backlog creation process to be able to view the backlog from the perspective of a particular role, in addition to the perspective of a particular feature group. So, how can I do that in the various tools?

Analog (3×5 cards) method
You can’t. A card’s place is represented by its physical presence. The only way you could do this is to make sure you make at least two copies of every user story (maybe in different colors) whenever you create one, and you put one in the feature group pile, and one in the appropriate role pile.
Usability: Very Low Downside: having two of every card is tedious, and means things will get out of sync. Don’t go there!

The Ideal Digital Tool
As I create the user story itself, when I type “as a ” I am then prompted with a pop-up list of all of the other roles I have ever created. I can select one, or I can make a new one. When I finish writing the story text, it will transparently pull the Role information out of the text, and use it to populate a ‘role’ field, a multi-select value field, or a relationship record, that allows me to find this story again by the role. If I don’t use the ‘as a’ template, I can still manage the role relationship directly, though the fact that I need to will encourage me to use the template. Or the tool will let you define a search pattern to extract the role so you can use your own story template. There may be a place in the application where I can define the relationships between roles. I will be able to filter any view by Role, or by multiple roles, quickly and easily. Ideally, I will be able to specify a full filter (where non-matching records are hidden) or a highlight filter, where matching records stand out from the rest, visually.

Excel
If you have broken the user story into three columns, one of which is the Role, then role based filtering/grouping is a snap.
Usability: High Downside: hard to have one record tell multiple stories (merged)

Mingle
When creating stories, you can add tags. So, for example, you might add a tag for role:Marketing to indicate that this user story is told from the perspective of the marketing stakeholder. Then, in any place where you can filter, you can filter to include only those items that have that tag.
Usability: Medium-High Downside: you have to remember to add the tag, and it does not support Highlight filtering, which can have undesirable side-effects

Rally
Like Mingle, you can add tags. Unfortunately, you can’t filter by those tags, so I’m not sure how good they are.
Usability: Medium Downside: Have to add the tag, doesn’t support any filtering on tags (that I can find)

VersionOne
You could co-opt the ‘Goal’ feature, and create a Goal for every Role in your backlog, and then associate them. This will allow you to have the many-to-many relationship that is needed, but then you couldn’t filter on it (I don’t think), you have to go to the Goals management screen, which is not ideal. And it is a hack. Or, you could define a ‘Role’ column, and pre-populate it with all the appropriate roles.
Usability: Medium Downside: If you forgot one, you need to have the administrator add it. And you can’t multi-select, so you can’t have multiple user stories in one backlog item, so you can’t merge them.

AgileOnDemand
Much like VersionOne, you can add a ‘Role’ field, and pre-populate it with options.
Usability: Low Downside: unfortunately, this doesn’t add the field to the WorkItem detail screen, so there is no easy way to set it. You can add it to the grid view, but then editing it is a bit tedious. Moreover, there is no clear way to filter by it.

Usability Comparison Summary on a scale of 1 to 10

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The goal of every sprint should be to create something that gives the business a sense of perspective, a frame of reference to use to direct future activities. What you deliver needs to work, at least in some respect or with some limitations, in order to offer the business that sense of perspective. If what you deliver can not be seen by the business, it adds no value.

“But it adds value to the development effort!” you might be thinking. Sure, assuming that your understanding of the direction that you need to go is correct.

Note that you are not simply taking a traditional development project and breaking it into 2-week chunks of work. You are creating a functional piece of software. It is all too easy to fall into the trap of breaking things down functionally, and then trying to map your functional decomposition into a backlog. Too often, you end up with pieces which can not stand alone, which do not deliver value to the business. The business can’t prioritize those kinds of things.

The problem is diving too deep. It’s so easy to do, too. You want to understand the problem, so you divide and clarify, divide and clarify, and at some point you magically and invisibly have gone beyond what you are trying to accomplish and have transitioned into the how of accomplishing it.

Therein is the secret of making sure your backlog includes only items that add value: They only tell you what it must do for the business, it does not specify how it is done. Review every user story, and ask yourself: “Is this telling me what the system needs to do, or is it telling me how the system works?” If it is the latter, change it to be the former. If you can’t, then you probably broke down the functionality too far, and that story needs to be rolled into another one that it supports.

It takes discipline, and maybe even a shift in ways of thinking, but you need to deliver something that “works” every time. It may be a mock-up or a prototype, it may not do everything it needs to do when initially delivered, but it is something that the business can see and wrap their brains around. The purpose of this is to empower the business to give their guidance sooner rather than later, and save everyone the frustration of wasted effort.

“But isn’t a prototype a waste of time?” Not really. Build it right and you can simply refactor it as necessary to make it into what it needs to be. And in the worst case, if you have to throw the whole thing away, you still ended up with valuable understanding of the problem, and that all-important frame of reference for the business to guide forward progress.

So, deliver working software. But deliver it often. Very often. Here’s why:

• If you have a term paper due in six months, what is the likelihood that you will finish it tomorrow? What is the likelihood that you will do the bulk of the work the night before it is due? The longer the sprint length, the more this tendency might rear its ugly head.
• The bigger the sprint backlog, the more overwhelming it can feel, whether there is any reason for it or not. So, the longer the sprint, the bigger the sprint backlog, the harder it is to focus, for some people.
• The shorter the duration, the sooner the business can give its feedback, the more Agile you become.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

There is an innate aversion to wasted effort. Nobody really wants to do something, only to find that they have to start all over again because what they did was not what was really wanted. In response to this aversion, people are naturally inclined to do more up-front planning. “If they just would have asked for what they really wanted, we could have delivered it, and it would have saved so much time!”

It’s true. If the development team were handed a detailed plan, and the plan were perfect, they would avoid a great deal of rework that happens when plans change. We all know it is true. And so, instinctively, we resist change, instead trying to push for “getting it right the first time.”

What we don’t always realize is that you could probably build it 3 times, two a total waste of effort, in the same time that it would take to plan to get it half-right. Yes, that’s right, there is something gained in doing it even if it’s wrong.

“What is gained in doing it wrong?” you ask? The short answer is “perspective.” You want to get from A to Z. A is where you are. Z is where you want to be. You think you know how to get there. Or maybe you don’t, but you know that the first thing you need to do is go from A to B. Once you have gotten to B, your position has changed, and so has your perspective. Now you have something tangible to look at, and that may reveal to you that Z isn’t over here, it’s actually more like over THERE. And now, it is a little more clear that the next step in the progression is C. Suppose it turns out that C didn’t get you any closer to Z. It was a waste, right? No. You have something tangible that you can point to and say “From here, we need to go in THAT direction.” It is the hardest thing in the world to say “I want to go in THAT direction” when there is no frame of reference. Giving yourself a frame of reference will accelerate progress by orders of magnitude more than the time wasted doing it the ‘wrong’ way. Besides, who says you won’t use C later on for something else?

So, a truly agile team, both in form and in mindset, welcomes change. Because when the roadmap is changing, that means that forward progress is being made. It means that previous unknowns are no longer unknown. The mature team realizes that if things aren’t changing, it could well mean that somebody isn’t paying attention to what you are doing. And that doesn’t bode well for anyone.