Pivotal Tracker

Hero image for Pivotal Tracker

With time and practice, the team has settled on a very particular and efficient workflow with Pivotal Tracker (abbreviated PT). Hereafter is the documented workflow.

Refer to this documentation when:

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

Nomenclature

To break down a large project into manageable -and meaningful- blocks, the team is 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 represent 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, 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, 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, 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).

To create this epic, 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.

To create this epic, 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.

To create this epic, 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 issue 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 the release story should be attached to a release epic.

Features

In this section, a sign-in feature has been utilized 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 workflow with the following names:

Template

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

Follow these three steps to get started with the template:

  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