Use case: shared backlog in version-specific product development

As a project manager or product owner quite often you may want to plan and track development of several versions of the same projects or products.

Example 1: I have an application which I want to develop for iPhone (iOS) and Android. It is two developers or two development teams and they will do the same tasks as the iOS & Android application has no difference. Common epics, features and user stories should be shared between both teams. The requirements are exactly the same. If we change the requirements, changes should affect both OS versions in the same time. We don't know how to manage the shared backlog without duplicating every entity.

Example 2: We have three similar versions of the same websites. They are in English, French, and Italian. These are three projects and we would like to create a user story to embed a social network login to each website version. Can we create a single user story valid for all three versions? Can we assign single work item to 3 projects at the same time?

In general, a work item (Feature, User Story or Task) in Targetprocess can belong only to one parent project at the same time. Keeping this rule in mind, several ways to handle your work are possible. Let us advise them one by one.

Several Projects with entire backlog copy in each one

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 work on your mobile clients on Project level. So you create:

  • iOS project with iOS-related work items (epics, features, user stories, tasks and bugs) and skilled developers
  • Android project with Android-related work items (epics, features, user stories, tasks and bugs) and skilled developers
Platform-independentiOSAndroid
Project+ (optional - master)++
Epic+ (optional - master)

optional relations

+ (copy)+ (copy)
Feature+ (optional - master)

optional relations

+ (copy)+ (copy)
User Story+ (optional - master)

optional relations

+ (copy)+ (copy)
Task+ (optional - master)

optional relations

+ (copy)+ (copy)

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. You have to keep the requirements in the single place. If you use copies of your requirements in your client-specific projects, you may forget to update copies together with your original requirements and then copies will quickly become outdated. This is why it is better to have references to the origin documentation in your client-specific projects rather than keep their copy-pasted details and try to have them updated.

In order to keep links to shared requirements, consider the following approaches:

  • Shared requirement is stored in the related Test Case or related Request. There is Relation between work item (User Story, Feature, Epic) and Requirements item (Test Case, Request). Once you update a Test Case or a Request, you can reach the updates from your works item by relation links.
  • 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.
  • Shared requirement is stored in the platform-independent common backlog item (Epic, Feature, User Story). There is manually added Relation link or ID:1234 shortcut from client-specific work item to the shared requirement item.

The following figure illustrates these approaches:

Platform-independentiOSAndroid
Epic, Feature, User Story, Request+relations, ID:1234 shortcuts
Test Case+ (master)shared by story test plans
Test Plan+ (master)+ (copy)+ (copy)
Documentation hosted externally(hyperlink)(hyperlink)(hyperlink)

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

  • Import backlog from CSV file
  • Copy 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.

Tracking Progress

In order to see overall progress you can group two projects under the same Program. You can also use shared cross-project Releases. Or you can create independent Releases and Sprints (Iterations) in each mobile project.

Platform-independentiOSAndroid
Program-shared
Release (cross-project)-shared (no iterations)
Release (project-specific)- + +
Sprint (project-specific)- + +
Team

Team Iteration

-+ (optional)+ (optional)

If your mobile development teams work on several projects in the same time it is possible to form iOS and Android teams and assign corresponding entities to their responsible team. This allows to plan teamwork by multi-project Team Iterations as well.

You will be able to track your progress:

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

Create two Features under single Epic

You may want to keep Epics in the common platform-independent projects. This helps to overview ongoing progress better in terms of functional areas. You can see percentage complete per each Epic (functional area) in this case.

Platform-independentiOSAndroid
Project++ +
Epic+--
Feature 

-

+ (copy)+ (copy)
User Story 

-

+ (copy)+ (copy)
Task 

-

+ (copy)+ (copy)

Track high-level progress on the Epics level and on the common Project level in this case. As soon as there is common Epic, and work becomes distributed by 3 projects actually, you shouldn't track progress on the Program level. It will show you different results in the cases when a Program includes all 3 projects or only 2 mobile client projects.

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

  • Import backlog from CSV file
  • Copy entire feature or even an epic with all its user stories from a platform-independent project to client-specific projects.

Create two User Stories under single Feature

If your project is not so large and lasts for 2-3 months, you may want to release the Features for both your applications synchronously, in the same order and (almost) without delays. In this case Features can be kept inside common platform-independent Project.

You may want to split work on your mobile clients on Project level or Team level. Then you can create:

  • Common platform-independent project to track requirements on higher level (features and releases)
  • iOS project or team with iOS-related work items (user stories, tasks and bugs) and skilled developers
  • Android project or team with Android-related work items (user stories, tasks and bugs) and skilled developers

Avoid using teams if your iOS and Android development teams are small and when they work only on the single project in the same time. Try to use client-specific projects and personal assignments in this case which is less complex solution and reduces mess in the system.

You can start to plan your feature set by creation of the list of Features and Releases in the common cross-platform project. Then inside each Feature for every requirement you should create two User Stories - one per each platform - and assign that stories to corresponding project.

Platform-independentiOSAndroid
Project+++
Epic+--
Feature+--
User Story 

-

+ (copy)+ (copy)
Task 

-

+ (copy)+ (copy)

If you have several developers for each mobile client and if your mobile development teams work on several projects in the same time it is possible to form iOS and Android team and assign corresponding tasks to their responsible team. In this case it is not needed to create separate client-specific projects. Do not assign mobile teams to your Features in this setup. Do it only with User Stories and Tasks.

You will be able to track your progress:

  • In common platform-independent project: by Epics, Features. If you don't use iterations, you may also track the progress on Releases level
  • In platform-specific projects: by Releases and Sprints (if you use single-project Releases), in Task Boards, by Team Iterations

Create two Tasks for single User Story

This approach fits best for very short projects with minimal number of stories and features. If your whole project can be finished within 2-3 weeks or even less and you would like to let your developers complete the user stories in the same order and as synchronously as it is possible, you may consider this workflow. It is recommended when you have from 2 to 5 developers per each mobile client.

In this setup everything is kept under the same multi-platform project. However, Tasks of the same user story are split by two developers using personal assignments or by two development teams using team assignments.

Platform-independentiOSAndroid
Project+--
Epic+--
Feature+--
User Story+--
Task-+

(personal assignment

or Team assignment)

+

(personal assignment

or Team assignment)

Team-+ (optional)+ (optional)

For each user story you may want to create two tasks:

  • Do it for iOS client
  • Do it for Android client

And later you assign responsible developers to each one.

Test-User-Story

Additionally if you have several developers for each mobile client it is possible to form iOS and Android team and assign corresponding tasks to their responsible team. Do not assign your User Story to mobile teams in this setup. Do it only with Tasks.

You will be able to track your progress:

  • In common platform-independent project: by User Stories, by Releases and Sprints, in Release and Sprint burndown charts
  • In platform-specific projects: by Tasks, in Team Iteration burndown charts

The following features can help you to automate Tasks creation and personal assignments:

Create two Custom fields for each User Story

This simplest approach fits best for very short projects with minimal number of stories and features. If your whole project can be finished within 2-3 weeks or even less and you would like to let your developers complete the user stories in the same order and as synchronously as it is possible, you may consider this workflow. It works well when there is only one iOS developer and one Android developer who work on the project.

In this setup everything is kept under the same multi-platform project and no teams are used also.

For each user story you may want to create two custom fields to reflect your progress:

  • Done for iOS client
  • Done for Android client

Here the cards and work items are not duplicated at all. However, the ability to track and report progress in detailed way on per-platform basis is sacrificed.

Platform-independentiOSAndroid
Project+--
Epic+--
Feature+--
User Story+--
Task+--
Custom Field-++

This is how the checkbox Custom Fields can be added in the process settings:

Custom-fields-settings

This is how the checkboxes can look like in the details view of a user story:

Custom-fields-info

And later you configure Custom Fields constraints mashup. It should prevent User Story from moving to Done when one of the checkboxes is not checked.

Do not assign your User Story to two mobile teams in this setup. Assign only developers to the User Story.

You will be able to track your progress:

  • In common platform-independent project: by User Stories, by Releases and Sprints, in Release and Sprint burndown charts
  • In platform-specific projects: by todo lists, filtered views and custom reports

This guide is a draft. 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.

Try for free

Account url: *.tpondemand.com
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy