Timelines for project portfolio management

As you probably know, we are implementing a new feature in TargetProcess 3: the Timelines.

Basically, a timeline is a projection of the cards (Projects, Features, User Stories, etc.) on a time scale. In the screen above only Projects are selected as cards. But it’s possible to show various cards such as Features, User Stories and Bugs on one and the same timeline.

Cards can be grouped by swimlanes, and each card type comes with a predefined set of swimlanes. In the screen above projects are grouped by teams.

Timelines are used in planning mostly for:

• project portfolio management
• people portfolio management
• roadmapping
• tracking project load, people load, team load

I’m going to publish a series of posts on using timelines. For a start, let’s see how they can help in project portfolio management.

You need to select projects as cards to be able to see them in a timeline:

Let’s take a look at how projects appear as cards on the time scale:

1. Project is planned but has not started yet. This card has dotted transparent borders.

You can update the start/end dates by stretching the card with drag-and-drop:

Note: TargetProcess 3 will never freeze the start/end dates for the planned projects, you can change them whenever you need.

2. Project is done. The card will stretch from the start date to the end date (that’s the time when all planned user stories and bugs are done).

Obviously, the planned and actual end dates may be different. We hide the planned end dates by default, but you can show them if the option “Planned in the past”  is on, to compare the planned and the actual end dates.

3. Project is in progress. The card is in progress from the start date till the date when we expect that the last user story will be done (the forecast end date). The actual (white) and the forecast (transparent) dates are split by the current date (the green vertical line).

The planned end date is also shown. If the planned end date is earlier than the forecast end date, the project will be delayed. Even more, if a project is delayed, and another project should kick off right after the delayed project was supposed to have ended,  this card for this project will be pushed to the lower line:

If projects are planned across teams, timelines can be used as an overview of the team’s projects. You need to select Teams as swimlanes:

You can move projects from one team to another by drag&drop.

There’s a field called “Owner” for Projects.  You can identify a Product Owner, Project or Product manager, CEO, etc.  as an Owner, and group projects by owners:

Projects can be also grouped by tags. For example, you can mark some projects with the “risky” tag just to make a note that a special attention should be paid to them,  or the “background”  - for the projects that people can work on if they have any gaps in their higher priority work. You need to select tags as swimlanes in the board config, and the timeline will look as follows:

The tags are not mutually exclusive. You can assign several tags to a project, and it will appear in several swimlanes.

If you still need mutually exclusive tags, you can create a drop down custom field as a workaround. This can be the case if there are several projects for Targetprocess and several projects for the fifteen puzzle.

In my next post I will show how to use timelines for roadmapping.

Better Multi-Teams Support Concept

TargetProcess3 has quite powerful multi-teams concept, but early beta release revealed some limitations. The main limitation is that you can't track functional sub-teams in a single project. That may sound like a waterfallish approach, but it is not in fact. There are many viable cases when this is useful (separate UX phase, separate deployment phase, etc.)

Another case is when several teams with different processes work on a single project. Imagine large projects with two development teams: Scrum and Kanban. Work split between these two teams, but we want to easily track progress on a project level.

The proposed solution will enable both cases above, but with a price of the system complication. 

User Story (Bug, Feature, Task, etc) will have two states: Team State and Project State. Team State and Project State will have mapping to each other. Thus a single Team can work on several Projects with different processes:

On the image below in the center you see typical Project states. Left flow (column) is a Kanban team that does development. Right flow is UX team. You see that Project State is linked to Team State. Thus you can easily track high level progress when creating a board with Project State. And can track Team progress when creating a board with Team State.

Project State - Team State mapping allows some automatic transition. For example, if we change Project State from Open to UX Phase, then UX Team State will be set to New. Team Status is something lightweight, it can be setup easily and mapped to statuses in various projects (thus a team with a defined flow can work in several projects with different flows).

The one restriction is that User Story has a single Team Status. Thus only a single Team can work on a user story in any given state. For example, when UX Team is completed User Story design, this User Story should be moved to Development (Kanban) Team. 

History is preserved, so it is known what teams worked on what user stories. However, history reports are complicated.

We don't expect to implement this solution in the next 4-6 months. Maybe more feedback will get us more ideas to improve multi-teams support. If you see any problems with the solution above, please share them.