APR: Prioritizing Use Cases – Vote Three Times

In our agile project case study we defined corporate goals and user personas, and from our understanding created a list of use case names. We refined those use cases into use case briefs, filtering out some of the use cases (for the first revision) narrowing the list to six use cases. In this article, we propose a prioritization of those use cases and ask you to vote to share your thoughts.

Use Cases

Here is the list of use cases that we’ve already defined, presented in what we think the priority order should be. Each use case lists the (primary & secondary) actors after the name of the use case. There appears to be an obvious separation of what to do first and what to do second. Each item also includes “first” or “second” in which represents scheduling use cases across releases. Each use case should be “completely released” within a single release (even if some of the functionality is quietly implemented during an earlier release cycle to make timeboxing more manageable).

Following the list is our thought process for proposing this order of importance. After that rationalization, we have three polls for you to vote on what should be included first. There are three identical polls to allow each of you to vote three times. We’re presenting the votes this way in order to allow you to express “passion” for a particular item – you can vote on the same item three times if you want (the results will be combined).

1. Browse An Area (Jill & Paul + Ellen). First.
2. Suggest An Article [Version 1] (Paul & All). First.
3. Rate An Article (Jill & All). First.
4. Search For A Topic (Jill & Paul + Ellen). Second.
5. Broadcast An Article (Paul). Second.
6. Comment On An Article (Paul & All). Second

Prioritizing The Use Cases

The first question is the chicken and the egg question. How can users browse without the ability to suggest? We put browsing first because browsing will happen much more frequently than suggesting. Note that version 1 of suggesting is the one we are prioritizing (user must submit the article through the site). Versions 2 and 3 are lower priority than the other 5 use cases here – if you disagree, please join in the discussion on this article and we will revisit.

Rating of articles follows immediately, because rating the articles makes browsing better, but you could browse without a rating. Ratings are placed ahead of searching because we think that searching is a “more is better” capability, where “rating” is one that is intrinsic to the nature of this site being effective. An interesting article from nForm on social networks provided some thought-guidance on visualizing the characteristics of a social network. Hat tip to Leisa at disambiguity for the reference.

Broadcasting slightly nudged out commenting because we think the ability to “market” the site will be more important when the site is first starting out – trying to reach a tipping point where the aggregate user contributions just “make it work.”

Voting To Promote Use Cases

Enter each of your votes here for the use cases that you believe should be in the first release (you may disagree with our analysis). If you want to share your thoughts, please include them in the discussion for this article – it may help convince others that your approach is better (getting more votes for your use case).

[poll=7]

[poll=8]

[poll=9]

Thanks for your votes, and if you selected “Other” – please explain in the discussion below. Note: I have placed two votes for Browse and one for Suggest – to show that I think browsing and suggesting are the most important use cases, and because I think browsing is more important that searching (which could work as an alternative approach).