Platform-Specific All Level Backlogs | Targetprocess - Visual management software

Platform-Specific All Level Backlogs

As a project manager or product owner you may want to plan and track development of several versions of the same project or support your product for multiple platforms. It is possible to track platform-specific project activities in Targetprocess. In this article we describe one of the approaches on how hierarchical mapping between your actual data structures and entities in Targetprocess can be configured. Other recommendations and best practices can be found here: Use Case: Platform-Specific Backlog

This approach suits best when you have powerful mobile applications with rich set of features in each other. Such projects can last for half a year or even several years. In this case we recommend you to split platform-specific work items (epics, features, user stories, tasks and bugs) on all levels.

Platform-Specific All Level Backlogs. Image 1

Moreover, backlog items related to platform-specific implementation can be kept separately from common requirements and design specifications.

Platform-Specific All Level Backlogs. Image 2

Platform-specific Projects

It is quite logical to organize platform-specific backlogs into independent Projects. So you create:

  • an iOS project with iOS-related work items (epics, features, user stories, tasks and bugs) and skilled developers
  • an Android project with Android-related work items (epics, features, user stories, tasks and bugs) and skilled developers

Platform-specific Projects

Features and User Stories are primary hierarchy levels in this setup, while Epics and Tasks can be considered optional.

Why do we recommend to consider both applications as standalone projects? Because actually in big projects there is always large amount of platform-specific requirements that should be considered in a very precise way. Within every mobile platform there is its own set of devices, screen resolutions, OS versions, design patterns etc. Large projects rarely go synchronously. However it is required to track all work items accurately. Not in all cases iOS and Android backlogs can be mapped one-to-one in terms of User Stories. Something can go wrong with your Android project and it can be delayed out of schedule and this shouldn't interrupt your iOS project. Or, you may decide to release your mobile clients with slightly different set of features. Having independent projects makes it all possible.

Shared Requirements

It is natural that your platform-specific clients may have the same functional requirements and design specifications. If you use copies of your requirements and design specifications in your platform-specific projects, it may be difficult to maintain them and keep updated in each project. As a result the copies become outdated. This is why it is better to keep origin requirements and design docs in the single common place and have references to them in your platform-specific projects.

Moreover this approach helps to split design and development phases when needed. As a benefit you can plan and track performance of design activities separately from platform-specific implementation.

In order to keep links to shared requirements, consider the following approaches: Related Requirement Entities, Template Projects, and Common External Documentation.

Related Requirement Entities

In this use case shared requirements are stored in the descriptions and comments of related Requests or Test Cases. The descriptions and comments of platform-specific work items do not contain any requirements. You manually add outbound Relations from every requirement item (Request, Test Case) to each platform-specific work item (User Story, Feature, Epic). You can reach updates in requirements from your work items within inbound relations.

Related Requirement Entities

Related Requirement Entities. Image 5

More information: Requests related to backlog items

Template Projects

Shared requirements are stored in the descriptions and comments of platform-independent common backlog items (Epics, Features, User Stories), and, optionally, related Requests or Test Cases. The descriptions and comments of platform-specific work items are initially updated from templates when work on the platform-specific project is started. Shared requirement items can be linked to client-specific work items within Relations or ID:1234 shortcuts. When you support a large number of platforms, it is quite easy to start new projects and clone the whole backlog from the template project to the platform-specific project.

Template Projects

Template Projects. Image 7

The following features can help you to speed up backlog creation:

  • Import backlog from CSV file
  • Copy an entire Feature or even an Epic with all its User Stories from a platform-independent project to client-specific projects. Then consolidate user stories from different platform-specific projects under their corresponding parent features in the platform-independent project, and delete redundant platform-specific features.
  • Webhooks — you define events and matching filters and create custom scripts. The script is launched automatically when needed and creates entire blank hierarchical structure of features > user stories > tasks.

Creation of items from templates is useful only when you start work on new platform. For further work it doesn't work so good. Once you perform a clone action the copied items become independent from the origin item. Automatic mirroring of changes in descriptions and comments of related items is not supported at the moment. When you change a description of an origin item or submit a comment to it the changes are not reflected in the related copies, and vice versa.

Common External Documentation

Shared requirement is stored in the external document (article). There is custom field of URL type that holds a hyperlink from each work item (User Story, Feature, Epic) to the requirements document. You may use Embedded pages mashup to display the content of this document inside Targetprocess. Once you update a document, you can reach the updates from your work items by hyperlinks or within special tabs. The descriptions and comments of platform-specific work items do not contain any requirements.

Common External Documentation

Common External Documentation. Image 9

More information: Embedded Pages

Tracking Progress

Platform-specific Projects

In order to see overall progress and manage your project easier as a whole you can group multiple projects under the same Program.

Platform-specific Projects. Image 10

You can coordinate and plan delivery within cross-project Releases. Work in each platform-specific project can be also organized into independent Releases and Sprints (Iterations). You assign User Stories, Tasks, and Bugs to both Releases and Iterations, and you assign high-level planning entities Features and Epics to Releases only.

Platform-specific Projects. Image 11

You will be able to track your progress:

  • In common platform-independent projects: by to-do lists, filtered views and custom reports, and also on the Program level. However, reporting on the Epic, Feature, and User Story level is a difficult and complicated task with this setup.
  • In platform-specific projects: by Epics, Features, User Stories using Release and Iteration burndown charts

Platform-specific Teams

If your mobile development teams work on several projects at the same time it is possible to form iOS and Android teams and assign corresponding entities to their responsible team. Moreover, separate Design team with activities related to design phase can be also created. This allows to plan and track teamwork by multi-project Team Iterations as well. You assign User Stories, Tasks, and Bugs to both teams and team iterations, and you assign high-level planning entities Features and Epics to teams only.

Platform-specific Teams

You can coordinate and plan delivery within cross-project Releases. Work in each platform-specific project can be also organized into independent Releases. You can assign all work items to Releases.

Platform-specific Teams. Image 13

This guide is a recommendation. Use it as a starting point, compare and test several approaches and let us know which workflow suits your needs best.

Still have a question?

We're here to help! Just contact our friendly support team

Find out more about our APIs, Plugins, Mashups and custom extensions. Join our community of passionate users and even discuss directly with our developers.