Process for using JIRA

The REQUESTER REPORTER of a story is responsible for providing criteria for DELIVERing CLOSing a story. For code implementation stories, this includes provision of a test.
Once the story has been evaluatued to be worked, it is moved from the RECEIVED state to the OPEN state.
The ASSIGNEE The OWNER of a story STARTs , FINISHes. Owners aren't assigned until the REQUESTER can evaluate delivery of a story.WORK on the story.
The ASSIGNEE of a story STARTs REVIEW of the story when the work is completed.
1. When putting the ticket into REVIEW, a link to the GitHub pull-request should also be included in the ticket
2. Note, the ASSIGNEE should STOP WORK on a story if they are temporarily changing focus to a different task.
The REPORTER (and/or the Tech Lead) The REQUESTER reviews/tests the finished code. Then DELIVERs the ticket and merges the code into the codebase. (Note, sometimes the Tech Lead will actually perform the code commit)
The Product Owner ACCEPTs or REJECTs a story.
A story can be in the ICEBOX without delivery criteria, but it must have an REQUESTER.
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.

A story cannot be in a spring without a REQUESTER, delivery criteria, and an OWNER.

either CLOSEs or REOPENs the story depending on the outcome of the review.
Once a story is CLOSED, the Tech Lead (or delegate thereof) merges the code into the codebase.

JIRA Workflow

Image Added

Jonathan requests the Glacier Mock story. It goes into the iceboxRECEIVED state. It has no ownerassignee. It has no acceptance criteria.
At the sprint planning meeting, we assign acceptance criteria and move the story to the backlogOPEN statue. The story has no owner assignee to do the work.
If the story goes into the current sprint, it may not have an owner assignee (Don't assign owners to assignee to stories outside sprints!).
At the next daily scrum, Chris decides to work on this story. He STARTs work WORK on the story, and makes himself the ownerassignee.
3 hours later, Chris is done with the work. Chris , makes a pull request, makes Jonathan the reviewer, and clicks FINISHand moves the ticket to IN REVIEW.
Jonathan (the requesterreporter) reviews the pull request (runs tests, etc.). When Jonathan thinks the ticket is complete, he accepts the pull request and clicks DELIVER in pivotal.
Some notifications happen, and Eddie creates a CHORE to evaluate.
Eddie ACCEPTs or REJECTs the story based on outcome of that choremoves the ticket to CLOSED.
If the work is subsequently revealed to be incomplete, Eddie REJECTs the Tech Lead REOPENs the story and moves it into the backlog.

...

Start work on the ticket in pivotalJIRA
Create an issue branch in your local git
When you believe the ticket is complete, push the issue branch to github
Send a pull request to master linking the pivotal JIRA ticket in the description
Link the pivotal JIRA ticket to the pull request or commit
Mark the pivotal ticket Finished
Link the pull request to the JIRA ticket
Move the JIRA ticket to IN REVIEW
The reporter The requester should review the change and, if it appears to be complete (including at minimum Integration and Unit Test coverage) merge into master
The requester should mark the ticket Delivered in pivotal, and provide a link to futures6 (or another public demo) demonstrating the change
move the ticket into CLOSED.
The reporter The requester should delete the issue branch in github
The PM or Tech Lead should evaluate the demo and Accept/Reject the ticket