Your software team has a process that use to complete work. Normalizing that process–i.e., establishing it as a workflow–makes it structured and repeatable, which, in turn, makes it scalable. With your development team, you can take an iterative approach to workflow management because it helps you meet your goals faster and exemplifies your team culture.
Simple is always best
When implementing a workflow for the team, always start simple. Fight the temptation to spend weeks (over-)engineering it. Overly complex workflows are hard to understand and adopt–not to mention adapt. Here are some necessary workflow states:
-
TO DO – Work that has not been started
-
IN PROGRESS – Work that is actively being looked at by the team.
-
CODE REVIEW – Work that is completed, but awaiting review.
-
AWAITING QA – Work that has been implemented, but is still waiting for a tester review
-
READY TO MERGE – Code that has been reviewed and is ready to merge into the master or release branch.
-
DONE – Work that is completely finished and meets the team’s definition of done.
In your issue tracker, these statuses flow from one to the next using transitions which structure the workflow.
The processes and steps required between each status
Approved
At this stage the developer is to create a new Branch, following the naming convention:
ticket – description
e.g.
DEV-3896 – Issues in Meter Group Analysis graph and drill down.
Coding Complete
Commit code to the server, using user branch above, this will allow for the code reviewer the ability to check this version
Happy code is all okay
QA will now take this branch and run it on their local machine to QA the story.
Any issues new sub-tasks of the story will be created.
Passed QA
Taking the branched code and moving the branch back to the trunk or the current main branch for that sprint.
Merged Branch
Ticket is closed
Reference: Using workflows for fun & profit