Proposal for using Pivotal Tracker

1. The REQUESTER of a story is responsible for providing criteria for DELIVERing a story. For code implementation stories, this includes provision of a test.
2. The OWNER of a story STARTs, FINISHes. Owners aren't assigned until the requester can evaluate delivery of a story.
3. The PRODUCT OWNER ACCEPTs or REJECTs a story.
4. A story can be in the ICEBOX without delivery criteria, but it must have an requester.
5. A story can be in the BACKLOG without an owner, but it must have delivery criteria. A story cannot be in the Backlog until the Product Owner has accepted it. A story cannot be Started until it has been assigned to a sprint.

6. A story cannot be in a SPRINT without a requester, delivery criteria, and an owner.

Example

1. Jonathan requests the Glacier Mock story. It goes into the icebox.  It has no owner. It has no acceptance criteria.
2. At the sprint planning meeting, we assign acceptance criteria and move the story to the backlog. The story has no owner to do the work.
3. If the story goes into the current sprint, it may not have an owner (Don't assign owners to stories outside sprints!).
4. At the next daily scrum, Chris decides to work on this story. He STARTs work on the story, and makes himself the owner.
5. 3 hours later, Chris is done with the work. Chris makes a pull request, makes Jonathan the reviewer, and clicks FINISH.
6. Jonathan (the requester) reviews the pull request (runs tests, etc.). When Jonathan thinks the ticket is complete, he accepts the pull request and clicks DELIVER in pivotal.
7. Some notifications happen, and Eddie creates a CHORE to evaluate.
8. Eddie ACCEPTs or REJECTs the story based on outcome of that chore.
9. If the work is subsequently revealed to be incomplete, Eddie REJECTs the story and moves it into the backlog.

Terms

• ICEBOX
  
  • Stories in the Icebox may not have delivery criteria. They may be rejected by the product owner from the Icebox.
• BACKLOG
  
  • Stories that have been accepted are moved to the Backlog.
• SPRINTS
  
  • Stories that have been started must be moved to a sprint.  Stories are finished and delivered in sprints.
• Pivotal Tracker States
  
  • finished
  • delivered
  • accepted/rejected

Proposal for implementing a fix or feature

1. Start work on the ticket in pivotal
2. Create an issue branch in your local git
3. When you believe the ticket is complete, push the issue branch to github
4. Send a pull request to master linking the pivotal ticket in the description
5. Link the pivotal ticket to the pull request or commit
6. Mark the pivotal ticket Finished
7. The requester should review the change and, if it appears to be complete (including at minimum IT coverage) merge into master
8. The requester should mark the ticket Delivered in pivotal, and provide a link to futures6 (or another public demo) demonstrating the change
9. The requester should delete the issue branch in github
10. The PM or Tech Lead should evaluate the demo and Accept/Reject the ticket