-
Notifications
You must be signed in to change notification settings - Fork 7
Lifecycle of a ticket
This column should contain cards that are :
- Stories that have gone through appropriate requirements analysis, design and user research testing
- If required, been discussed during a Tech Review session to note coding stategy
- Sized during a Refinement session
- Production defects or issues identified
- Blockers to the team's ability to deliver (e.g. broken build pipeline, expired certificates etc.)
- Developers should pick tasks up from this column as they become available.
- Tasks should be ordered by priority.
- Developers should be encouraged to pick up tasks in priority order, not simply cherry pick the tasks they like doing. This will help spread knowledge and develop expertise within the team and reduce bottlenecks when certain individuals are unavailable.
- Developers should not pick up tasks from this column until they have completed any in-flight tasks they may be working on. If there are blockers to them completing the in-flight tasks, then we should focus on removing those blockers rather than adding additional tasks and increasing the backlog further down the line.
This column should contain cards actively being worked on. In most cases there should be a maximum WIP limit of one task per developer unless a task is blocked but it is reasonable to expect the task to be completed within the sprint, but there may occasionally be fewer cards in this column, for example if developers are pairing up on a task.
- Acceptance criteria has been met.
- Adequate automated test coverage is in place.
- Yarn tests and linting are successful.
- Pull requests should contain a description of the change, some context about why the change is being made and detailed instructions on how to review/test the change.
- Pull request URL has been noted to the JIRA card.
- All automated checks/travis build etc have gone green on the pull request. This gives the reviewer some confidence that the change is good. Review should become easier and less burdensome as a result.
Cards that have met all the definitions of done in the development column should be moved here. Once in this column, it is the developer's responsibility to get his/her task reviewed by the team since they cannot pick up another task until their card has left review.
- At least two independent approving reviews verifying the change.
- The attached PR should have been approved.
- All automated checks should be green (because they were green when leaving development)
- Any review comments resolved and re-reviewed where necessary.
- Noted PR merged into the master branch.
Cards that have been reviewed and the PR merged into the master should be moved here. Once in this column, the Product Manager will review the changes in Staging.
- PM signs off that the changes meet the acceptance criteria and design specified
Cards that have been reviewed and accepted by the Product Manager should be moved into this column. The card will remain in this column as the changes are released into PreProd and finally into Live. As changes are released into Pre-Prod and Live the card status should be updated appropriately.
- READY FOR PRE-PROD - Default status when card is moved into the column
- PRE-PROD
- Runner - Stable environment for Business users to review changes prior to release to Live
- Author - PM is responsible that regression testing using the Capability Examples Questionnaire is completed prior to release to Live
- DONE - Changes have been released to Live
Implemented cards are kept in archived sprints.