Chirag was a new lateral joinee to one of the teams that I had coached.
After his first week, Chirag approached me with a question: How many statuses should I define in my workflow, so that I know where exactly a story is, so that I can intervene as a scrum master.
In my previous company, I had followed this scheme:
In this project, the team is using this:
In our retrospective, there was one suggestion from a member, that was endorsed by two more team members, which is more like:
While this seemed somewhat like what I have used in the past, I feel that this has fewer statuses and so, in my stand-ups, the update may not truly reflect the progress.
The present scheme, I was explained, was created after considering some of the repeating challenges of adhoc or reprioritized work resulting in work to be halted half way [Paused].
They had similar reasons why the other statuses were also defined.
Shiv, please tell me which scheme should I adopt?
What will be your recommendation. You can also share your inferences from the above 3 options.
Suggested Solution
My answer would be what may possibly be the most common response from a coach: ‘It depends’!
But seriously, it surely depends.
In the three examples that Chirag had shared, there were reasons why these were found as needed.
The first, I could infer was that some bottlenecks were being experienced in Peer review and QA and that visualization would highlight any issues in these areas early, so that the team can adjust their priorities to de-bottleneck
The second scheme, though catering to the reality in terms of the current practices, will require a deeper review of the practices, as the symptom indicates some adhoc-ism and reprioritizations happening frequently, that would upset the rhythm of an iteration. This also reflects possible bandwidth crunch for QA and Verification. The team would greatly benefit by addressing the underlying causes.
In this case, since the team felt that this needs simplification, it is a positive first step.
In the third option, peer review could again be a challenge that needs to be addressed.
If the team has sufficiently small tickets [stories], in-progress should be a fresh list every day! So, based on what the team wants to improve, choose the status accordingly and make it easy to update the status and also make it easy to transition from one state to another while being watchful of the causes for any out of the ordinary transitions.
