Archive

Archive for April, 2015

The Three Levels of Prioritization. Or, how to eliminate scope creep and always deliver on time.

April 23, 2015 1 comment

tl;dr

The Three Levels of Prioritization:

  1. Must haves
  2. Nice to haves
  3. Wish we could have

——————————————-

I wrote some time ago about Themes in Scrum.  The focus of that blog post was to address the issue of lower priority items in the Sprint backlog.  The idea was to be purposeful in planning around potentially low priority topics such as help and tutorial pages, or documentation.  Click here if you are interested in reading.

Over the years I have learned much about prioritization – both as it applies to backlog grooming, and how it applies more generally. Proper prioritization is the key to keeping your sanity as a Product Manager. The magic of good prioritization:

  1. Forces stakeholders to think about what they truly need and what they can truly live without.
    – the problem isn’t identifying the top priority, it really is identifying priorities 2, 3, 4, and so on.  And most importantly, which items are the lowest priority – which items will not make the cut if push comes to shove.
  2. Sets expectations
    – everything can’t be top priority.  If we agree to work on the top priority items, that means we are not working on the lower ones. At least not right now.
  3. Manages scope and feature creep
    – when new priorities pop up – or stakeholder focus shifts – always ask the question “is this important enough to stop what we are doing now?”.  Or, “if we work on this, what can drop off the list of deliverables?”
  4. Always deliver on time
    – It’s virtually impossible to deliver both a promised set of features AND on a promised delivery date.  However, a hard delivery date can always be met if the feature set is flexible, and the feature set is always flexible in Agile – it is the Product Manager’s job to convince the Stakeholders of this.

How to always deliver on time

After you have forced your stakeholders to think about what they truly need and can truly live without, then managing scope creep and delivering on time are all a simple matter of proper prioritization.  .The first step is to construct a long-term, agile roadmap.   Remembering that in Agile, requirements and priorities can change sprint-to-sprint.  This does not mean you should avoid creating a long-term roadmap, it simply means that it must be constructed in such a way as to maximize flexibility and minimize wasted development cycles.  Use the following three steps to create a flexible, agile, roadmap:

  1. Identify the Minimum Deliverable Feature set
    – sometimes called the MVP – Minimal Viable Product.  If production where shut down unexpectedly, which features would allow the product to still be delivered in some form or another?
  2. Identify dependancies
    – which features provide basic functionality that can be built upon in future iterations, You do not want to start with standalone features that don’t support the broader functionality of the product.
  3. Prioritize the major features into 3 categories:
    • Must haves
    • Nice to haves
    • Wish we could have

While items 1 and 2 deserve attention (maybe in a future post), let us focus on item 3 – the 3 categories for prioritization. Must haves are features that the product can not live without.  These define our MVP.  Nice to haves are features that we would really love to build – features that add real value, maybe features that differentiate our product from the competition – but are not part of the MVP, and at the end of the day, we could deliver without.  Wish we could haves are the “wish list” items. Everybody agrees these features would be great, these features add pizazz and polish to the product, but expectations are low that these will ever be delivered.

The Wish we could have list is the most difficult one to create.  Some might be tempted to put fit-and-finish issues – the polish – into this category.  However, prioritization is dependent on the goals for the product.  Are you trying to simply get to market quickly with an MVP?  Or differentiate your product from the competition with attention to detail?  Apple, for example, would probably consider fit-and-finish as a Must have feature, whereas a start-up company with a brand new technology that just wants to get a foothold in the marketplace might define only basic functionality as the Must haves – fit-and-finish is on the wish list.

With this prioritization scheme in place, it is now easy (relatively) to commit to a delivery date. The commitment date will include all of the Must haves, as many of the Nice to haves as possible, and maybe some of the Wish to haves.  Always schedule time and resources around the Must haves and the Nice to haves. That way, the Must haves will always be delivered.  Unexpected roadblocks might result in some Nice to haves getting dropped, while any overestimations in time or resources allow some of the Wish we could haves to be delivered.

The 3 levels of prioritization as a fractal

To achieve the greatest level of success with this methodology, make sure you apply it to every level of the planning process.  Apply it to the MVP and the high-level roadmap.  Then apply it to the Epics within each major product feature, and again to each User Story within each Epic.  Finally, use the 3 levels in Sprint planning to fill each Sprint with Must have and Nice to have stories.  Time permitting, bring in extra Wish to have stories, or drop Nice to haves when things don’t go quite as planned.  As priorities change over the course of the project, you as the Product Manager can reshuffle what is being worked on without sacrificing the Must have features and stories, and will be able to articulate at any point in the project what is being worked on, what is being delivered, and why.

%d bloggers like this: