Timelines for Roadmapping in TargetProcess 3

In my previous post I shared some tips about using timelines in TargetProcess 3 for project portfolio management. Today I'll write how to create project road maps with the timelines.

By roadmapping we understand high-level planning of a project. To be more exact it’s planning of project features. Features in TargetProcess are containers of user stories. Feature cards are marked with the green bars, as on the screen below.

Is there any other way to do a project road map in TargetProcess 3, without the timelines?

The timelines are still in development, and for now you can use a workaround to road map a project. Check the screen below. We've  done the TP3 project road map with the drop-down custom fields: Q1 2013, Q2 2013, etc. 

This approach works but it’s quite limited. Some features can take more time than a quarter (3 months), some features can be started at the end of the quarter. Besides, you can’t see the duration and the forecast completion date for the features in this setup.

Some of these issues can be solved if the roadmapping is done with releases. But in our opinion release and strategic planning should be separated.

The concept: roadmapping a project in TargetProcess 3 with timelines

Simply put, we want to implement roadmapping in TargetProcess 3 as on a whiteboard:

For that,  we're going to add the planned start and end date fields to the features (actually, not only to the features, but to all the assignables: features, user stories, tasks, test plan runs and bugs) and make it possible to change those dates on the timeline. If a feature is selected as a card, the timelines will look as follows:

The cards have dotted borders (which means they are “planned’), "actual" borders (coloured with gray if a feature is done, and with white if it’s in progress; "actual" means cycle time for a feature) and the forecast end date (transparent). See a more detailed description of the cards in my previous post.

Backlog
All the features that have not been planned yet are in the backlog, ranked accordingly.  An unplanned feature can be moved from backlog to timeline by drag-and-drop. Features will retain their default duration when moved to a timeline. It was very tempting to calculate the duration automatically based on the estimates, and a lot of people asked us for that. But this auto-calculated duration would actually be a forecast made when a feature has not yet gone to “work in progress”. Obviously, this auto-calc would be too approximate, and hardly of any use, so we decided to provide some leeway.

Swimlanes
You can group features by a project, team, assigned people, priority, release, state, tag or a drop-down custom field. That’s how features grouped by projects look on the TargetProcess 3 board:

You can see the vertical line on the iOs project swimlane. This is a planned start date for this project. The rule of a thumb is:  if an entity selected as a swimlane has some planned start and end dates, these lines are shown in the background. The borders for releases and teams will be shown in the same fashion.

Conclusion
As you can see, the timeline is quite a flexible framework. You can select which cards to plot on the timeline. You can group the selected cards by swimlanes. You can change the planned start and end dates as you move cards, and compare the actual progress with the forecast - because you can see both. And it works for all the entities.

Next time I will show how to use timelines for tracking the project load, people load and the team load. You’re welcome to share your thoughts and post questions here.

*edited by Olga Kouzina

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.

Design Concept: Customize Cards on Boards

We are finalising cards customization on boards.

On the left you see various zoom levels, so it will be possible to customize cards for all zoom levels. In the center you see card template and a list of all available properties on the right. 

You can quickly search for properties and use drag and drop to customize card. Rearrange properties easily:

Most sizes are fixed, so you can't put more than several properties on small sizes.

However, large sizes are unlimited, so you can put as many properties as you want (but card will be quite large in this case).

Your feedback is welcome!

New Navigation for Boards and Reports

We are working on Custom Graphical Reports concept now and are thinking about navigation changes. The main idea is to allow reports creation very similar to boards creation.

So left menu will break down to 2 sections: Boards and Reports. If you click on a section title, it will open Overview page with all Boards (or Reports) thumbnails. These thumbnails will be actually real snapshots (they can be captured every 30 minutes for example). So Overview will show many boards/reports with almost live content.

In the future we are going to add Dashboards, so there will be 3 sections: Boards, Reports, Dashboards.  

What do you think about this idea?