As a project manager or product owner, you may want to plan and track the 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 a 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.
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
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 a 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 a slightly different set of features. Having independent projects makes it all possible.
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 a single commonplace 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 the 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
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.
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 (Deprecated. Please consider using Automation Rules instead) — you define events and matching filters and create custom scripts. The script is launched automatically when needed and creates the entire blank hierarchical structure of features > user stories > tasks.
- Automation Rules — a functionality that applies triggered responses to changes within or outside of the application.
Creation of items from templates is useful only when you start work on a new platform. For further work, it doesn't work so good. Once you perform a clone action the copied items become independent from the original 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 original 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
Tracking Progress
Platform-specific Projects
In order to see overall progress and manage your project easier, 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
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 the 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.
Still have a question?
We're here to help! Just contact our friendly support team