...
Jira Workflow Columns
Todo
Blocked/Questionable
In Progress
In Code Review
In Deployment
In QA
In PO Review
Done
Status Transitions
Blocked/Questionable: Move the story here if some impediments or uncertainties need resolution.
In Progress: Move the story to In Progress when development begins. During the development process, a developer should move the story to the most relevant project in JIRA. There shouldn't be any stories in the EUREKA project that have PRs. If there is a need to make the code changes in multiple projects - create a story per project and link them to the main bug or story.
In Code Review: After Move the story to In Code Review after development is complete and a PR is ready, move the story to In Code Review. If it is a bug, a developer should fulfill the RCA field should be fulfilled by the developer.
In Deployment: After deploying the code to the Kitfox Dev Rancher Environment for developer testing and validation, move the story to “In Deployment” and merge the PR to the master branch. All Before the merge, all comments in pull requests should be marked as resolved before the merge.
In QA: After deployment to the Kitfox Testing Environment, and when the QA team begins testing, move the story to In QA.
In PO Review: Once QA has verified the story and it's ready for Product Owner (PO) review, move the story to In PO Review.
Done: Move the story to Done after the PO has accepted the story and there are no critical issues are remaining.
Acceptance Criteria
All acceptance criteria outlined in the user story must be fully met.
Critical Bugs
Ensure there are no open critical bugs associated with the user story before moving it to Done.
...
Demo Environment
All features eligible for demonstration should be demoed from the shared Kitfox Testing Environment.
Team Presentation
The story must be presented to the team during a demo session (if demoableapplicable).
The Product Owner (PO) moves the story to Done if there are no critical issues.
...
Documentation
Document all spike findings on the wiki and present them to the team.
Place PoC findings in the team's space on Confluence.
Code Accessibility
Check PoC code into GitHub to make it accessible to the entire team.
Follow-up Actions
Create user stories to implement or formalize the preferred approach or solution , (if applicable).
Share the resulting Jira issues with the PO for awareness so they can ensure the issue metadata (labels, features, etc.) is accurate and complete.
Acceptance and Recording
The PO and the architects' team are responsible for accepting after spike findings are presented and discussed.
...