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 OWNER ASSIGNEE of a story STARTs WORK on the story.
- The ASSIGNEE of a story STARTs , FINISHes. Owners aren't assigned until the REQUESTER can evaluate delivery of a story.REVIEW of the story when the work is completed.
- 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 reivew.
- Once a story is CLOSED, the Tech Lead (or delegate thereof) merges the code into the codebase.
JIRA Workflow
Example
- 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.
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.
- finished
- delivered
- accepted/rejected
Process for implementing a fix or feature
- 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 commitMark
- Move the pivotal JIRA ticket Finishedto IN REVIEW
- The requester reporter 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