Section 6 · Pivotal Tracker Tutorial
On this page 8 headings
The lecture demonstrates Pivotal Tracker, a tool for tracking user stories and velocity, including signing up and creating a project. This is a historical demonstration: the service ended on 30 April 2025.
Set up a project and understand its workspace
The tutorial begins by creating a project named “IIT Software Engineering Project.” It shows the current iteration or prioritized backlog, an Icebox of unprioritized ideas, the iteration-length setting and team membership. The example uses an iteration length of two weeks.
The Icebox is a holding place for stories that are not yet selected or prioritized. The working backlog contains stories that the team has considered for near-term development. Team members can be invited so responsibility and progress are visible within the tool.
Create a feature story with tasks and links
The tutorial creates a feature story such as “Add Catalogue Item.” It selects a feature type, assigns an illustrative 2 story points and priority, and adds a description, labels, optional source-code links or attachments, tasks and comments. Two example tasks are “Create and Review UI Screen” and “Create Catalogue Database Table.”
A story records user-facing functionality; its tasks describe the concrete work required to implement it. An owner is responsible for progressing the assigned story. Saving a story records the plan—it does not mean implementation is finished, delivered or accepted.
Epics group related user stories
An epic is a collection of related stories describing a broader area of functionality. The tutorial groups Add/Edit/View/Delete Catalogue Item stories under the Catalogue Management epic, while Add Inventory Item is linked to the Inventory Management epic.
An epic is not the same as a task checklist. A user story delivers a meaningful slice of capability, whereas a task may be a database table, UI implementation or testing step needed to complete the story. Grouping stories helps the team see progress across a larger feature.
Move ideas from Icebox to planned work
Customer feedback and order tracking are added to the Icebox as ideas to implement in the future. The current iteration holds Add catalogue item and Add inventory item (feature, high priority, 2 points each); velocity set to 4.
Feature-story lifecycle: start through acceptance
A feature story moves from Not Started to Started while a developer works on it. The developer documents work, completes tasks and marks the story Finished. Clicking Deliver sends a status update to the product owner, who reviews comments/links and accepts or rejects the story.
The Product Owner checks the functionality, notes and links and can Accept or Reject. Acceptance records that the delivered story meets expectations. Rejection returns it for further development; the developer restarts work, corrects problems and submits it again. “Finished by developer” and “Accepted by Product Owner” are different milestones.
When a delivered story is rejected
The lecture demonstrates the Product Owner rejecting “Add Catalogue Item” with feedback such as failing test cases and too many bugs. The developer reads the comments, fixes the implementation, retests the affected scenarios and delivers the story again.
The story should remain unaccepted until the Product Owner reviews the improved delivery. Comments, linked code and task history create an audit trail of what was attempted and what changed. This makes the tool valuable for team coordination rather than just counting checkboxes.
Analytics: improve the next iteration
The tutorial also discusses analytics including accepted stories, rejection rate, story cycle time and recent epics. The team can use these to ask whether stories are waiting too long for review, whether feedback commonly triggers rework or whether work is moving steadily.
Quick recall
- Icebox ideas are not the same as prioritized current-iteration stories.
- Stories can carry types, points, labels, tasks, comments, code links and owners.
- Epic = group of related stories; story = user-facing capability; task = implementation step.
- Finish → Deliver → Product Owner accepts or rejects; rejected stories require rework.