Workflow
Once a ticket has been accepted and marked as ready for work any developer of the development department is allowed to implement it.
We are focused to deliver, this means that our focus is in reverse order of the defined workflow. E.g, review over in progress items
Triage
Incoming bug reports or feature requests. Feature requests not tied to the roadmap are normally backlogged. Unless it is a quality of live change with low impact.
Backlog
Planned work that is tied to a roadmap item or maintenance.
Refinement
Tickets selected for next sprint. These will be refinement in the planning session. If clarified that will become ready for work, otherwise they go back the backlog.
Ready for work
Tickets that are ready to be worked on.
In progress
Tickets that a developer is working on.
Review
Team collaboration moment. Review code and test it together.
Reviewers should add themself as reviewer on a merge request.
Review step includes: - code review and discuss changes - approve the review when done - last approver merges changes to master in conference with author - deploy to acceptance - functional test on acceptance
To go from review to done: - A release must have been created (if necessary, depends on pipeline). - Deploy to production must have been successful. - Manual check on production, do some kind of sanity check
Done
Work is deployed to production and users are (un)happily using it.
Once a ticket is done it can no longer be altered. Thus any changes must be handled through new tickets. Tickets are not reopened when done.
Tickets remain done, until end of sprint, after that they are closed.