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.
Moreover, backlog items related to platform-specific implementation can be kept separately from common requirements and design specifications.
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
Features and User Stories are primary hierarchy levels in this setup, while Epics and Tasks can be considered optional.
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.
More information: Requests related to backlog items
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.
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.
More information: Embedded Pages
In order to see overall progress and manage your project easier as a whole you can group multiple projects under the same Program.
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.
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
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.
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.
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.