Backlog Prioritization in
MANDAROON
In preparing to start our build (well before our first sprint), we assess what our knowns and unknowns are. Perhaps our team has built similar login systems before. Setting this up and estimating how much time it will take will be very straightforward.
Implementing sound files, however, is something no one on the team has done before. Before trying it, we will not know how if we can do it, or if we can do it within a reasonable amount of time. This represents a very significant risk.
If it is a key feature, of the product, we will want to find out early if it won’t be worth implementing. If we’re going to fail, we want to fail as early as possible, when we have made the smallest possible investment of developer time/salary and of team emotional investment (i.e., morale).
If we determine that we can build the feature for a reasonable amount of money, but it will take more time than we have for the first product release, we will want to adjust our build and release strategy so that our first release will still be received well and that the timing of the sound feature will make sense to them.
We may even want to work with our marketing team to begin creating buzz for the feature release when we are very confident that it will be released soon.
Ordered Features
Below is an example backlog of product features. For clarity, they are not listed in standard story format. In fact, most of them would represent epics, and will need to be “refined” further into stories in order to be incorporated into sprints. The next section will address the refinement process. Following each is a rationale for its placement, based on backlog prioritization principles:
- Business Value (BV)
- Risk / Uncertainty (RU)
- Sequential Necessity (SN)
When possible, BV will take precedence, but the backlog items reveal when RU and TV sometimes must prevail, particularly early in the earlier stages of development.
Part 1 – The Minimum Viable Product
1a. Basic Registration / Login System
This will be a simple, straightforward login system, simply allowing a user to create an account, consisting of a username and a password, both of which can be edited later. Once logged in, logging out and other related options will be accessed from the “profile” icon in the bottom menu. In the first build, there will be no options for using existing email or social media accounts.
Rationale: TN. To release even the simplest iteration, a user will need to be able to create a secure account. At this stage, we will keep it as simple as possible, as the app makes no attempt to distinguish itself in this area; it should only to be up to user’s current expectations of a respectable app.
1b. Bottom Menu
To start, only two items (and therefore 2 icons) are necessary in the bottom menu:
 |  |
| Home | Profile |
Rationale: TN. The product needs a menu, and a user needs to be able to log in and out from their profile. Still, we keep these features to an absolute minimum, since they represent nothing unique to the product (i.e., clear business value).
1c. Vocabulary Menu For An Example Lesson
The home screen can consist of the first example lesson: a list of vocabulary items, consisting of one item per row, with 4 columns:
sound | characters | pinyin | English | dropdown button
Rationale: BV. This is the core of the product. Most key features will attach to this frame.
1d. Column Title & Item Toggle Buttons
Column titles are clickable, as are individual items in each column. When the titles are clicked, they hide or unhide all items in that column on the page. When individual items are clicked, they also hide/unhide their content.
Rationale: BV. This is the minimum functionality for the product to function as a study tool.
Part 2 – Mitigating Risk
2a. Pronunciation button for each menu item
The first item in the vocabulary listing. A button that plays a sound file of the vocabulary item. The sound file is to be taken (if possible) from a 3rd party, such as Google translate.
Rationale: RU. Yes, it also provides BV, but the main reason for placing this feature so high in the backlog is because the feature is considered highly valuable, but also most risky (i.e., hard to estimate how it will be built and how much time it will take to build).
2b. Dropdown Panel with Item Analytics
When the dropdown button is clicked, a panel opens as a row below the vocabulary item. The panel contains a list of sentences in the lesson text in which the vocabulary item occurs.
Rationale: RU. Developing the dropdown is trivial, but developing the code on the backend that will iterate through lessons and identify all sentences will likely take more time than other features. There’s a higher-than-normal possibility that unexpected questions/issues will arise during the build.
2c. Finding & Inviting Other Users to a Group / Lesson
For each lesson, the creator will have the ability to add other users as viewers or collaborators.
Rationale: RU. The invitation process will ideally allow for multiple means of identifying other users (email, phone number, etc.), and will have multiple means of confirming / accepting (clicking a uniquely generated URL, pasting in a confirmation code, etc.). The final workflow will depend on how complex the implementation of each feature proves to be.
Part 3 – Finishing Out Basic Features & Maximizing Business Value
3a. Lesson Menu
The home page becomes a container for a list of lessons, and the example lesson becomes its first item. Clicking on a lesson opens its list of vocabulary items. Clicking an “add” button allows for the creation of new lessons.
Rationale: TN. This is a mundane feature, but a requirement for scaling up.
3b. Vocab Notes in the Item Dropdown Panel
This feature allows the lesson author to add notes (including their own example sentences) to a container within the item dropdown panel (where analytics are also stored). The author can choose which notes/sentences are visible to other users. (Later, other users will be able to up/down vote the notes, and the notes will be sorted from most to least popular.)
Rationale: BV. This is a key feature of the app, which sets it apart from both generic dictionaries and from flashcard apps.
3c. Vocab Hints in the Item Dropdown Panel
Similar to the vocab Notes feature, the Hints feature appears within its own container in the item dropdown panel. There are multiple hint categories, which are displayed horizontally as follows:
character | radical | appearance | sound | meaning
The author (and eventually other users) can add individual words or characters that they believe have a connection to the words/character(s) in the vocabulary item in question. Each category contains its own list. (In the future, users will also be able to make their own contributions and to up/downvote other users’ contributions).
Rationale: BV. This is another unique feature to this product.
Parts 4, 5, 6 & Beyond
Clearly, there are many more features to be developed. The selection above is simply an illustration of how to approach prioritization. In the next section, the same items will be refined with varying degrees of detail.