Pivotal Tracker
A guide to how we use Pivotal Tracker, our favourite software project management tool.
Epics capture high-level goals associated with a feature, and usually consist of many stories (and bugs).
It isn't compulsory to have Epics in every project, but they do help in maintaining a sense of "achievement" within the team. Simply completing story after story, fixing bug after bug, can get monotonous... and "completing" an epic marks the end of a consolidated effort by the team.
The smallest part of a feature is called a User Story. It is a concrete, well-understood, independent unit of work that can be delivered to the user for some demonstrable value (n.b.: also see Chores).
Stories are estimated by using a "points system" before they are started.
A purely technical task that does not add demonstrable value to any user of the system. It is important to track such chores because they add value to the overall project. For e.g.: refactoring code, upgrading dependencies, adding automation scripts.
A feature in production that does not function as expected. 💔
- A question related to a story that needs to be answered before that story can be worked on.
- A dependency where another story needs to be completed before a story can be worked on.
A marker in the Backlog that represents a version to be delivered or a milestone to be achieved. All stories "above" a Release marker must be delivered and accepted, before the due date.
A prioritized list of stories to be worked on during the current iteration. An iteration is usually one (1) week long, but this can be configured in Pivotal on a per-project level.
A prioritised list of stories planned to be worked on in the upcoming iterations.
An unprioritsed list of all stories, chores, and bugs. Items from the Icebox are added the Backlog during prioritisation discussions, usually an Iteration Planning Meeting.
Last modified 2yr ago