Pivotal Tracker

Hero image for Pivotal Tracker

With time and practice, we have settled on a very particular and, in our case, efficient workflow with Pivotal Tracker (abbreviated PT). Hereafter is the documented workflow.

You should refer to this documentation if you:

  • Need to scope a project,
  • Need help understanding a new project.

Nomenclature

To break down a large project into manageable -and meaningful- blocks, we are relying on Epics and a Label Nomenclature for user stories. These two components are tightly linked together as labels are used to associate user stories to epics.

There are four types of epics defined as follows:

  1. Module
  2. Feature
  3. Release
  4. Standard

Module Epic

  • Module epics represents the main components of an application.
  • Module epics are the smallest denominator to which the app can be reduced to. It often corresponds to navigational sections (i.e. each navigation menu item points to a component of the app).
  • A module epic contains several feature epics.
  • There are recurrent module epics such as User Account and User Profile (those are, by default, in the project template).

In order to create module epics, we follow this nomenclature:

  • Epic Naming: Module - Module Name (all text must be in bold)
**Module - Module Name**
  • Label Naming: #the-module-name (# character is used)

Feature Epic

A feature is a coherent and standalone group of user stories that defines a functionality in the application.

In order to create feature epics, we follow this nomenclature:

  • Epic Naming: Feature - Feature Name (Feature must be in italic)
*Feature* - Feature Name
  • Label Naming: $the-feature-name ($ character is used)

Release Epic

  • A release can either be a version or a milestone.
  • A release contains several user stories. An entire feature epic can be delivered in one release, or throughout multiple releases.

In order to create release epics, we follow this nomenclature:

  • Epic Naming: Release - 0.1.0
  • Label Naming: @0.1.0 (@ character is used)

Standard Epic

These epics are recurrent in every project. They do not relate to a particular feature of the app, but to the app itself, in its entirety.

APPLICATION

  • The Application epic regroups all user stories that have an application-wide impact.
  • Often corresponds - but not limited to - application setup tasks.
  • Often corresponds to user stories of type chore as these tasks do not deliver a feature but are necessary for the implementation of features (e.g. implementing error pages).

We follow this nomenclature:

  • Epic Naming: APPLICATION (all text must be in bold)
**APPLICATION**
  • Label Naming: !application (! character is used)

QA

  • The QA epic regroups all user stories resulting from internal and external feedback, and bug reports.
  • User stories in this epic will initially not have any module epic attached to them. This epic serves as a bucket for all QA issues. Eventually, each story will be labeled with the corresponding module, feature and release epics.

We follow this nomenclature:

  • Epic Naming: QA (all text must be in bold)
**QA**
  • Label Naming: !qa (! character is used)

TESTS

The TESTS epic regroups all user stories related to new or existing application tests.

We follow this nomenclature:

  • Epic Naming: `` (all text must be in bold)
**TESTS**
  • Label Naming: !tests (! character is used)

Issue Types

In addition to the main isssue types (Feature, Bug and Chore), PT supports an additional type:

  • Release: a milestone in the development process, usually meaning the release of a new version in which case you must attach the release story to a release epic.

Features

In this section, we’ve seen a sign-in feature as an example for almost all the sub-sections. Now, here is the complete example of a sign-in feature spec’d down.

Note that the front-end story is on the left, and the back-end one is on the right. Sometimes the front-end story will have more details, sometimes the backend story will.

Example Story

All markdown titles are displayed the same, regardless of hierarchy. Using one single # for titles is enough.

Statuses

Issues go through the default development states with the following names:

  • Unstarted (default): it corresponds to the status Todo.
  • Started: it corresponds to the status In Progress.
  • Finished: it corresponds to the status Code Review.
  • Delivered: it corresponds to the status Ready for Testing.
  • Accepted: it corresponds to the status Accepted.
  • Rejected: it corresponds to the status Rejected.

Template

To get a quick start for new products, a project template is available in PT.

You can get started with the template in three steps:

  1. Export the template (make sure to check all the boxes when exporting),
  2. Create a new project in PT,
  3. Import the template in the newly created project.

The following screencast illustrates the export / import process.

PT Project Template