EN 
JA 
IT 
ES 
The Status Simplification
I’m making a big assumption here, but I’m guessing that your teams use Jira to hold product requirements? It’s not really a big assumption either, over 65,000 companies use it globally so I’m just playing the odds. Jira is amazing…but for all of its amazing features, the customisable workflow is the one I’m going to discuss…because it bugs me.
Each PBI in your Product Backlog has a lifecycle. It is created, likely worked on, and then completed. Simple, right? Every team that I have ever worked with use Jira workflows to model their PBI lifecycle and it’s very effective. Here is an example:
The Development Team move each PBI through the statuses until the work is done. But have you ever noticed that there’s always that one team member whose work is sitting in ‘Open’ and then announces in the Daily Scrum ‘oh yeah, sorry, it’s almost Done, I just didn’t change the status’. Is it their fault for not keeping the status up-to-date? Or is the process just over-complicated?
Is the complexity in the workflow really worth it?
To answer this, we need to consider the purpose of the Sprint Backlog. It is an artefact that shows the Development Team’s forecasted plan to achieve the Sprint Goal. It is inspected (and adapted if needed) daily. Importantly, it is transparent. In my experience, when Development Teams inspect their Sprint Backlog, they talk of things like, ‘Yeah, I’m just about to integrate that work’ or ‘Nope, it needs some more manual testing before releasing’…if they are giving this level of detail, consider who the complex Jira workflow statuses for? Ask your teams! After all, it’s their process.
I asked my Scrum Team this and the answer was…. *shrug*. After some Five Whys, we broke this *shrug* down to three things:
- The Development Team don’t need the complex statuses. They know the in-depth status of their PBIs.
- The Product Owner didn’t use the statuses either. All they wanted to know was whether the Sprint Goal was likely to be met.
- The benefits of complex statuses were external (the ‘complementary’ roles of Project and Release Managers).
Scrum aficionados will know that the guide doesn’t explicitly reference any ‘states’ a PBI should transition through (good, because it’s a framework, not a methodology 😊). But, are some implied? In my mind, YES!
Firstly, ‘Done’ – a PBI that meets the Definition of Done is ‘Done’. Secondly, a PBI that has just been created is ‘To Do’ or some such term. And thirdly, only by extension, a PBI that is neither ‘To Do’ or ‘Done’ is….Doing? In Progress? Whatever you want to call them, could our Jira workflow just be ‘To Do’, ‘In Progress’ and ‘Done’? It’s certainly not for me, as the Scrum Master, to decide this. The process is owned by the Scrum Team. But I think this simplification is helpful because it provides a more simple, common language for the team to reference.
If you’re thinking, my team use a more complex workflow and that works for us…that’s brilliant! If your process works, cracking! But ask yourself who the complexity helps – do the people who need to know the progress of PBIs, already know? Are you trying to replace communication by complex statuses? Is there value in the complexity? If not, let your teams consider it and see how they want to self-organise around a solution.
Just think, how simple could everything be:
Are there some downsides with this simple workflow? Here are the questions my team fielded to me and my paraphrased responses:
What happens if a PBI gets blocked by external factors?
Fair question. We could add a status in for blocked. But if the PBI is blocked by another team, is progress still being made on it? Are you still involved in its progress? So, could it just stay ‘In Progress’?
What happens if we need to hand off a PBI for Testing?
Scrum is a framework that is employed by cross-functional teams. The Development Team are responsible for all of the work to turn a PBI to Done. Are we regularly passing off work to other teams? Why?
How can I show progress is being made on a larger PBI if it’s just ‘In Progress’ for ages?
Communication with the Product Owner. If the PO knows that progress is being made, his responsibility is to keep his stakeholders up to date. If you feel pressured that you aren’t demonstrating progress, how do the team feel we model Trust? Or, could we learn from this and decompose our PBIs into smaller chunks?
I’ll leave this post there. I know this simplification won’t be everybody’s cup of tea, but if you take one thing away from this, please remember that a complex Jira workflow shouldn’t replace good ole’ fashioned verbal communication and transparency.