Process to Define and Achieve Technical Improvements

What you'll learn

The 3-Step Process for Technical Improvements

Conducting a Technical Assessment (Discovery Phase)

Creating and Prioritizing a Technical Backlog

Integrating Technical Initiatives into the Production Roadmap

When you are running a production based mobile product, it can be difficult to identify and define meaningful long term technical improvements.  Even more difficult is successfully implementing a plan to achieve success on the defined tasks.

In this post we will attempt to outline a simple 3 step process to help you identify, plan for and achieve success with long term and yearly technical improvements.

The three steps in their simplest forms are (1) The Technical Assessment, (2) The Backlog and (3) The Production Roadmap

1. Technical Assessment

The discovery phase

The first step is to take an accurate technical assessment of your product.  The purpose of this step is to identify the current status and/or health of all of the technical components of your product.

Start by creating a word document.  Provide a list of all of the major technical pieces and areas that your product is involved in.  This includes all code bases and languages you use, data stores and caching mechanisms you employ, and also performance areas that are critical to you apps success.  An example list might look like the following (abbreviated):

• Memcache
• MySQL
• Frame Rate
• Memory Usage
• Loading Times
• User Blob Size
• C++
• (etc)

Now expand this list with sub bullets describing the current state, good or bad, of the technical area listed.  Try to keep the sub bullets confined to small and short sentences.  This is to help you identify high level issues or problems, not to outline all possible solutions.  An example of your expanded list might now look like the following:

• Memcache
  • On an older version, need to upgrade.
  • Data footprint being stored is ### in size and needs to be reduced.
• MySQL
  • Query count has doubled in the last year and needs to be reduced.
  • It's been 6+ months since we last analyzed "Slow Queries"
• FrameRate
  • Frame rate is currently within targeted ranges
• Memory Usage
  • Memory use has increased slowly over the last 6+ months
• (etc)

Keep in mind, that at this early stage, the purpose of our list is not to find solutions, but rather identify status and surface problems.

Once you have the list in a decent shape, start sharing it with your other technical leads.  Ask for their input on items that are not included, but should be.

2. Technical Backlog

The prioritization phase

The next step in our process is to take our technical assessment and start to fill out a technical backlog.  The backlog in it's simplest form is a roughly prioritized list of actionable tasks.  Basic information such as swag cost estimates and difficulty levels may also be included to help with planning tasks.

When creating your technical backlog, it is important to keep the tasks specific and well defined.  Including open ended tasks with no clear exit will be difficult to use in the next phase, which focuses on scheduling.  For example, if we have a task that says "Fix Memory Usage", it will be very difficult to schedule and quantify success of that task.  By contrast, if we provide a task that says "Remove redundant textures to improve memory", it will be very easy to schedule an appropriate amount of time for that work as well as judge whether or not the work was successful in reducing our memory footprint.

You will want to use your technical assessment doc to help you create your technical backlog.  While doing this, it is important to keep the two separate from each other.  The technical assessment focuses on status and high level goals, while the technical backlog should focus on specific tasks.

If your team or product has a team wide backlog, it is up to your discretion whether or not to utilize their's or manage your own.  We would offer that if the team backlog does not have a way to view the tech only tasks in an easy to view fashion, you may want to use your own.  The reason for this is that you will want to constantly review and revise your technical backlog as priorities changes.

Example technical backlog.  Although the exact view of your backlog may vary, here is an example of what it could look like.

• Upgrade PHP to #.#.# (~30 days).
• Increase APC storage (~2 Days).
• Run Unity profiler to identify duplicate textures (~2 days).
• Add new payment funnel logs (~1 day)

It is important to always keep your technical backlog prioritized.  In this step, we are not doing any scheduling and thus have no deadlines.  The top item on the list will generally be considered the most important and will usually be completed before the ones below it.  Revisit the prioritization of your backlog regularly and don't hesitate to move items around as business needs and direction change.

When prioritizing items on your technical backlog - be sure to look for items that may have hard deadlines associated with them.  For example, upgrading an iOS SDK may not be high on our personal priority list - but may need to be done before a certain date in order to avoid issues.  Take these items into account when re-prioritizing your backlog, as an item may quickly jump up in priority if an external deadline is approaching.

3. Production Roadmap

The scheduling phase

The last step in our process is to get items out of our backlog and onto our production roadmap for delivery.

Depending on your team structure, there may be very different beliefs on how much time of a production roadmap should be devoted to technical backlog initiatives.  A healthy ratio is about 10% - 15% of a production roadmap.  This value will of course vary depending on short term needs and overall production goals.  If your app is not in a healthy state revenue wise, it can be very difficult to justify technical initiatives.  While treating this topic in depth is out of scope for this article, we would briefly recommend compromising on the short term if needed, but stand firm on the need to perform technical initiatives and upgrades to ensure long term health of your app.

Be sure to keep your roadmap, backlog and technical assessment all separate.  These are all 3 different documents with very different purposes and goals.  Use your technical backlog to help fill out the roadmap as needed.  As you move items from your backlog to the roadmap, make adjustments as needed to the costing depending on who will be doing the work.  Some engineers may handle one task more efficiently then others.

Production roadmaps look very different depending on the team, but below we will provide a brief example of a roadmap that may be used.

• Release "C"
  • Feature: Weekly Race Contest
  • CRM: Valentines Day Sale
  • Technical Backlog: Increase APC Storage
• Release "D"
  • Feature: PvP Challenge version 2
  • CRM: New Push Notif Format
  • Technical Backlog: Unity Profiler
  • Technical Backlog: New Payment Logs

When pulling items off your technical backlog, keep in mind that you might not be able to take the first item off the list.  In one release you may only have 5 free days of work, and thus you should take the first item that fits into that time slot.  If you find that you are skipping large tasks frequently, then you may need to re-evaluate their size and break them up into smaller deliverables so that they can be properly scheduled.  In the example below, our PHP upgrade will be a very large task and thus we will see more success by breaking it up into smaller, more meaningful milestones.

• Release "E"
  • Feature: Improved FTUE
  • CRM: 4th of July Sale
  • Technical Backlog: Upgrade PHP Milestone 1
• Release "F"
  • Feature: Collection Mechanic
  • CRM: None
  • Technical Backlog: Upgrade PHP Milestone 2

Conclusion

Despite sounding incredibly daunting, defining and achieving success with yearly technical goals is possible.  It is not a light feat though and requires a lot of thought, planning and dedication.

Start simple, make a small technical assessment that focuses on your top 10-15 technical components.  From that assessment, derive out several action items for each component.  Then over time, slate these action items into the roadmap for delivery.