Put iOS 9 Into Your Product Backlog Now

Awesome. You have a mobile app built on iOS 8.3. The problem is, when Apple releases iOS 9, your app might break and you will lose customers.

I am going to share some techniques with you on how to manage this risk and potentially avoid all problems, while keeping the rest of your business well aware of the activities of your engineering team. While this is not the only way, this is an approach I used in the past which has resulted in a positive outcome.

Beta-time!

Apple provides beta releases of iOS. Because they make it available, you have the ability to explore new features, but also, see what still works and what breaks in your existing app. This is the key to the framework I am going to share.

The framework for managing this kind of work is as follows:

• Test Through Stories
• Fix stuff
• Repeat

Test Through Stories

Since the backlog is the source of work the team works from, you can create a user story in your backlog to test your app. Here is a sample user story:
As a product owner, I want to know what issues my app has with iOS 9, Beta 1, so that I can prioritize fixes.

Note how the story is specific. iOS 9, Beta 1. There is no ambiguity what needs to be tested. The purpose is clear. You want to know what the issues are. The team knows this story isn't to make sure the app works with iOS9, Beta1, but rather to find what doesn't work.

The acceptance criteria might look like:
The application is tested on an iPhone 6 running iOS 9, Beta 1
All defects are entered into our bug tracking system

You may want to have different stories for different target hardware devices such as iPhone 5S, iPhone 6, iPhone 6 Plus, iPad Air 2, etc.

When the team completes the story, during the Sprint Demo or Sprint Review, the team can demonstrate the app running in the new iOS build, summarize the defects found, and highlight some of the of the key defects that were discovered.

Future Stories

Although Apple hasn't released additional beta versions of iOS 9, it is safe to assume more will come out and you can put those into your backlog now. Doing so will provide more visibility to the team and business of all the work the team needs to do, as well as any impact to schedules or other features. I will touch on this topic more in the Repeat section towards the end of this post.

Additional Considerations

Some behavior might be perceived as a defect, but could be a flaw of the beta release of iOS. The team will have to be very careful in evaluating each defect and making a determination or best guess as to what the cause of the defect might be. To play it safe, document everything so that you can retest it in a future release of iOS.

See What You Did There

In brilliant fashion, you leveraged the process and tools at your disposal to protect the product and incorporate technology updates into the backlog and roadmap. The business now has greater visibility and awareness of changes in the technical landscape. The team also appreciates your forethought to anticipate this kind of inevitable change. Well done.

Fix Stuff

Now that you have a list of things that are broken, you can prioritize those items in the product backlog, just like you do with everything else. Some defects you will be able to fix, and some you won't (perhaps due to schedule pressure or other constraints). Hopefully, you will be able to get all the necessary fixes in place before iOS 9 goes live.

As mentioned before, some defects might be related to unfinished features of iOS 9 and some might be proper compatibility issues such as consuming an obsolete API. Refer to the iOS documentation to help making this assessment and ensuring the proper fix is put in place.

Repeat

You will also have to decide if you want to test every beta version that is released. This will be a function of budget. When you have a lot of automation, or if testing is cheap, then you can play it safe and test every version that is released. If testing is very expensive and time consuming, you might not have the luxury to test each version, and will have to decide what versions will be skipped.

Looking at iOS 8, there were 5 beta releases with the first on June 2, 2014, a gold master release on September 9, 2014, and public release on September 17, 2014. This means you had 14 weeks to test, fix, and release you app while maintaining new feature development. That is 7 two-week sprints. Depending on the release schedule and frequency of iOS, you could have been testing 6 out of the 7 sprints.

On a past project, we made the deliberate choice to skip some beta releases due to other feature priorities. We skipped the first, third, and fourth release of iOS 8, but tested with the others.

Retrospect and Celebrate

After that last minute crunch to fix those final pesky bugs before the iOS 9 GA and you get submit your app to the App Store, take a breather. The team worked hard and discovered many new things. There might have been some realizations about the application architecture that could have made the compatibility with iOS 9 a little easier. Work these observations and architectural improvements into the backlog to better position your product for iOS 10!

Also, celebrate with the team. Buy them food, silly shirts and nerdy gadgets. This might have been a major or minor release of your product. Show your appreciation and gratitude to the team who made your product success possible.

Best of luck and happy coding.