A Primer on Prioritization
If you are about to embark on a mobile project, get ready to hear the term “prioritization” thrown at you endlessly. From triaging bugs, to planning out your release milestones, mastering prioritization is key to successful mobile app projects. Prioritization is the process of attaching a value to a task/feature/scenario and then ordering what gets done based [...]
If you are about to embark on a mobile project, get ready to hear the term “prioritization” thrown at you endlessly. From triaging bugs, to planning out your release milestones, mastering prioritization is key to successful mobile app projects. Prioritization is the process of attaching a value to a task/feature/scenario and then ordering what gets done based on priority.
When you are planning a mobile app release, you will use prioritization to attach value to the scenarios you are looking to enable with that release. You will use these priorities to schedule when specific items are developed and how you prioritize bugs that emerge during development. Prioritization allows everybody on your team to understand what is most important and what they should be working on.
The prioritization model I like to use is a simple 3-choice priority scale that we used to use back in my time at Microsoft:
Priority 0 (P0)
P0s represent the highest priority items to be completed. A P0 is defined as something so critical to the release of the product that you would hold the release to include/fix it.
By definition there should be no outstanding P0 tasks at the end of the release, otherwise it wasn’t a real P0.
Priority 1 (P1)
P1s are high priority items, but they aren’t necessarily things you would hold up a release for. Releasing a product with outstanding P1 bugs is painful, because a P1 is still a major bug that someone might notice yet it is one you will have to live with. An example of a P1 bug would be your app not being able to install on an older iPhone. While this is might be a major bug, it usually isn’t enough to warrant you holding up the entire release of your product to fix.
Priority 2 (P2)
P2s is the ‘other’ bucket where bugs end up when they aren’t important enough to be considered P1s. You should view P2 items as things that are “nice to have”, rather than “must have”. P2 items can be anything from changes in color schemes or re-designing UI flow.
A sad reality of app development is that there are usually so many P0s and P1s that you might not ever get around to something marked as a P2. Typically the first few beta releases of an app are so chalk full of bugs or missing functionality that P2 bugs only ever get fixed in the final release once the app has stabilized. Prioritization is your friend, learn how to use it, and develop your own scale for what you think a P0 is versus a P1. Prioritization only works if other people believe the priorities are valid, so its important to make sure that you are consistent and predictable when evaluating bugs and features.
Until the next article, keep on prioritizing folks!