You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I know that the answer to this question (discussion) may depend on what was determined within the team, but maybe you have some general advices. Let's say that developer is working on task (status: IN PROGRESS, assignee: that developer). Then, the developer thinks that he finished the task and he creates merge request / pull request. How do you think, this is the right moment to change task's status to RESOLVED and/or change the assignee (the task is waiting for code review)? Or maybe developer should click stop progress (change status to OPEN) and does/doesn't change the assignee? Do you have any other views?
I concur with @Warren - if we have Tasks which need to go through various stages - or Stories which go through development and testing prior to release, we have separate statuses these move through to visualise progression.
It depends what you're trying to achieve though - why would you go with either of your options? What is the benefit of having it in a TO DO or DONE status category, as opposed to an IN PROGRESS one.
For our teams, the work remains IN PROGRESS whether it's being worked on or suffering from wastage time. An option for you if you wanted to visualise IN PROGRESS vs TO DO would be to have "Ready for Dev", "Dev", "Ready for Analysis", etc, where the Ready statuses are TO DO category.
I would be careful of creating too many - you don't want a workflow with 50 statuses unless its useful / needed.