Skip to content

Workflow: Using Pivotal Tracker

Ashley Engelund edited this page Sep 16, 2017 · 16 revisions

We use PivotalTracker. SHF PivotalTracker

Here's our workflow:

(It looks complicated, but it's not. The diagram tries to show all possibilities. )

PivotalTracker workflow v 1.0

'entry' = what you do when you enter the state. Ex: When you go to the Waiting for Client state, you first press the Deliver button

'exit' = the last thing you do so you can leave the state. Ex: The last thing you should do in the Started state is to make sure all_rake_tasks_pass

Labels in PivotalTracker

  • We assign a label for the current sprint in the form sprint XX Ex: sprint 24

  • If a task in the Backlog or Icebox (a.k.a "backlog") has been addressed/finished/accomplished by some other task (it's been done because of overlap or duplication), then:

    • we'll label it with the current or upcoming sprint so that we see it in the list of items we need to talk about in our team meetings (PivotalTracker will put it into the list of items for the sprint, which is what we go through and review in our team meetings),

      and

    • we'll label it needed? to denote that the task may have already been addressed.

    Ex: the labels for the item (task) in PivotalTracker will be sprint 24 and needed?


How was that diagram made? This is all represented by a state machine in ruby code. It's a PivotalTrackerFeature class that includes AASM (the Acts As a State Machine gem). The diagram is generated with the aasm_statecharts gem, which reads that class and then uses ruby-graphviz to actually generate the .png file.

Clone this wiki locally