Plan 49 – Basic Principles

Can you put that sign up page redesign on the development planning? Sure thing, item number 304 to be completed by next year.

Scheduling development work isn’t trivial. Short term, everything is supposed to be agile, but what goes into your next sprint? As discussed, it can’t just be the next item on an ever growing list or a gut feeling.

So what do we need?

  • objective data to determine priorities, you can’t keep trying to compare every item to every other item
  • priorities needs regular revising
  • the way priorities are set, depends on the working area
  • not every type of task has comparable priority, so instead you need to value the category as a whole
  • it’s easy to ignore certain aspects of a business or project that will hinder your progress as a whole ( e.g. marketing or security )

This is what forms the foundation of Plan49:

Your business has 7 critical areas that you need to keep moving and within each area there is always a ‘next up’ and a horizon of 6 more items that will come after that. Of course you can have a bigger backlog, but these 49 items are what you can reasonably think and reason about. Everything else that does not fit those 49 items either lacks evidence or just isn’t important.

For each area you need to have some formal way to determine priority, but it does not need to be the same.

An example set up for a small company could be :

  • New product features
    • prioritized based on:
      • + nr of times requested by customers
      • + nr of times requested by new leads
      • + extra revenue estimate
      • / estimated time required
  • Security
    • prioritized by
      • * impact
      • * likelihood
  • Marketing / New leads
    • prioritized by:
      • + number of new leads
      • / estimated time required
  • Sales / Conversion optimization
    • prioritized by:
      • + time saved per lead
      • + expected conversion rate improvement
      • / estimated time required
  • User Experience
    • prioritized by:
      • + percentage of exits at this point
      • + number of related support questions/feedback
      • + percentage of users impacted
      • / estimated time required
  • Bugfixes and Support
    • prioritized by:
      • * severity of the issue
      • + percentage of users impacted
  • Quality and Reliability
    • prioritized by:
      • + number of related issues in past 3 months

You may disagree on such cold factors to determine priorities by, but what is the alternative? The most vocal customer? A gut feeling? What someone feels like today?

So assuming we could prioritize within each area, how do we end up with what we actually work on next? This is where we take into account how much progress you already made in an area compared to the others as well as that we propose that no area should be neglected for more than 90 days.

The most bare-bones approach would be to simply round-robin the areas. Ideally the items in our plan are roughly 1 to 2 weeks work for a team which ensures that every area is touched at least once every quarter. Then we may choose to prioritize marketing, user experience and bugfixes a bit more and ‘visit’ those areas twice in every cycle.

So what are the benefits of this approach?

  • provide focus to your team
  • center your scheduling around critical themes for your business
  • take away uncertainty and doubt
  • provide transparency how scheduling choices are made

If you are interested in applying this approach, don’t hesitate to contact us and sign up for the newsletter.