Process for using
...
JIRA
- The REQUESTER of a story is responsible for providing criteria for DELIVERing a story. For code implementation stories, this includes provision of a test.
- The OWNER of a story STARTs, FINISHes. Owners aren't assigned until the REQUESTER can evaluate delivery of a story.
- 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.
JIRA Workflow
Example
- Jonathan requests the Glacier Mock story. It goes into the icebox. It has no owner. It has no acceptance criteria.
- 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.
- If the story goes into the current sprint, it may not have an owner (Don't assign owners to stories outside sprints!).
- At the next daily scrum, Chris decides to work on this story. He STARTs work on the story, and makes himself the owner.
- 3 hours later, Chris is done with the work. Chris makes a pull request, makes Jonathan the reviewer, and clicks FINISH.
- 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.
- Some notifications happen, and Eddie creates a CHORE to evaluate.
- Eddie ACCEPTs or REJECTs the story based on outcome of that chore.
- If the work is subsequently revealed to be incomplete, Eddie REJECTs the story and moves it into the backlog.
...