We’ve recently worked on several mobile app development projects for tablets and phones running iOS, Android and Windows. Thanks to these projects, we’ve identified some key do’s and don’ts for managing your product backlog requirements for mobile application development efforts.

Here are some of the common business features and technical requirements/constraints for both consumer-facing apps and corporate internal apps that could show up in the product backlog:

• Responsive UX Design (screen size, orientation, device features, etc.) – for this you will need to identify a limited set of target device configurations for acceptance
• Required corporate branding/corporate style guides
• Choosing between a native app style UI that is device specific vs. a common style cross-platform UI
• Stringent speed/performance targets for initial app loading, screen navigation, response to user actions
• Connected vs. Disconnected Operations requirements – you need to clearly define what features work when there is no connection
• Data security and Personally Identifiable Information (PII) protection
• Support for multiple OS and multiple versions of an OS
• Support for multiple types of mobile browsers
• Integration with companion apps on the device
• Cloud/web service integration to access corporate systems of record
• App Store submission requirements (i.e. Google Play, Apple App Store and the Windows Store). Each store has its own unique sets of UX requirements, minimum performance, storage management, legal/copyright, privacy notification requirements, content age appropriateness designation, etc.
• App version management
• Code-sharing across device and OS platforms
• Graceful degradation of the app functions in case of failures
• Process improvement support, especially for corporate vs. consumer apps that are targeted for mobile workers
• Security and device management for corporate apps

The items in the list above may all need to be considered when you first start working with the product owner to both build the product backlog for the mobile app and help define the overall scope and timeline for the project. For consumer apps deployed through app stores in particular, the timeline for publishing to the stores — and factoring in the review and acceptance process — needs to be considered up front.

The mobile app projects we’ve worked on tend to be relatively fixed budget projects with fairly aggressive delivery schedules.  Often these projects are highly visible within the client’s organization, and in some cases executive management may be directly involved in the definition and approval of the business features and visual design for the app. It is important to work with the product owner to devise strategies for bounding requirements discussions, and setting limits on the number of iterations the requirements are allowed to go through before stabilizing the product backlog and moving on to the initial sprint planning.

Here are some of the key lessons learned to date:

Some Do’s for Product Backlog Definition

• A dedicated client product owner/advocate is a must to maintain focus and establish clear priorities.
• Scope management is the key to success – this cannot be emphasized enough!
• Clearly define the target users – Why are we building this app? Who will really use this app?
• Define platforms and form factors early.
• Define points of integration with systems of record and external data sources early on as well.
• If this is your first app, educate yourself (and the product owner) on app store submission requirements and the time required to go through the process.
• A clear acceptance criteria/definition of “done” for each feature/story is a must.

Product Backlog Grooming

• Ruthlessly prioritize features (YAGNI) against budget and schedule constraints
• Everyone has great ideas…but will users really need it? Or use it?
• Is it really a Minimal Marketable Feature?
• “Glitzy” features are not always useful, and can be expensive to build and maintain
• Negotiate and simplify features whenever possible

Product Backlog Item Elaboration

• Storyboarding/Wireframes of key user stories/scenarios are a must to define features scope.
• Show examples of wireframes/mockups on actual target devices, if possible.
• Elaborating on individual feature/user story requirements through specific test scenarios is recommended.

And here are some important “Don’ts” for managing your backlog items…

• Don’t….allow the discussions on the initial development of backlog features to go too long… or too wide.
• Don’t…defer details of system interfaces – feasibility analysis is important.
• Don’t…defer details of what end user device features components will be leveraged.
• Don’t…forget to consider metrics collection needs for understanding app usage and related reporting requirements.
• Don’t…allow (too) many iterations of UX specifications.
• Don’t…wait until the end to think about app store submission requirements.
• And don’t…wait until the end to research legal-related items (trademarks, content classification).

It’s important to keep in mind that mobile app development projects are considered by many organizations to be “cool” and cutting edge, and thus garner a lot of attention (and ideas for features) from within all levels of the organization.  Keeping focus and defining the absolute minimum marketable features set for the initial release of the app is critical to getting the app deployed on time and within budget.