More Statuses, More Success (in Jira)

"OMG, there are so many statuses in this Jira workflow! Dave, what the heck??"

There is a method to my madness:

I feel that many product managers get too focused on the Scrum/Kanban boards when working in Jira. I can see why - it is the first thing you choose when setting up a project, and people spend a ton of time working on the boards. But the boards are just a tool - they need to serve the team, not be the primary focus of a product management effort. 

Instead, we need to focus on the people - from the person who initiates an idea to the person who researches it, designs it, architects it, validates it, writes up details, actually does the work, tests it, accepts it, deploys it... there are a ton of people and a ton of steps to go from an idea to a product feature. The workflow from idea to delivered product feature needs to be about communicating with those people, not just running an agile process.  

The trick is to build a workflow that handles all those people, while not making them have to deal with the size and complexity of it all. Let everyone do their day-to-day job seeing their own view of the world, a simplified slice of the bigger picture. 

I achieve that with big workflows that contain many statuses, but that also provide a simple UX for each individual person within the process:
I create a status for everyone who might have any need to think about, plan, or act on any piece of work. I build a workflow that connects the statuses in the right order, with specific transitions between statuses so nobody ever sees a huge drop-down of statuses to choose. Team members see work that is available either do some of the work and finish it, or send it back to the me for more information.  

I also set up a board for each role. You'll have a Dev Board, a Testing board, a PM board, and maybe even a Sponsor board. Dev boards look just like they do on any other team, and the other roles just see some basic To Do and In Progress columns for their own work. 

The PM glues it all together by seeing the work on their own board. They triage new cards to decide whether or not to go forward with new work or backlog it. They refine the ideas into fully baked product features. They look at work that has been completed by UX or other roles, and either refines it more or moves it along to the next role. When all the planning is complete, it goes to dev to be added to the product. 

A Sponsor/Stakeholder board is something I also use that is not typical, but is effective. I do not actually expect executives to get into Jira and read up on features we need to discuss, but having a separate board for them makes it easy to have a specific agenda for calls. You can run a meeting with clear goals - to answer questions and confirm designs and plans for specific work, gain consensus, and move forward.

Cards will bounce around the boards a bit as work is planned - a new feature may be written up by a PM, get a wireframe from UX, discussed with stakeholders, refined again, re-worked into a full design, written up into final requirements by the PM, then finally sent on to the Dev team. All of that happens anyway, but supporting it in a single workflow helps to be sure that nothing falls through the cracks, and you can re-prioritize efforts along the way as needs evolve. 

So what does this all actually look like in Jira? Here is an example workflow of how these ideas may come together:

Is it a lot? Sure... but it gets the job done. 

I do get resistance to all this because it is more setup and complexity. It also becomes too process-driven for some product folk. But for analytical folks like me, it works quite well. When I've been able to run products using this type of setup, we ended up with few meetings, effective async communications in the cards, and happy team members.