Product Roadmap and Jira Portfolio
I have an interesting challenge around my Product Roadmap (I'm a PO). As a scrum team we've been moving to more modern agile practices like only refining stories just before a sprint, not estimating far ahead but using cycle times for predictions, treating the roadmap as a prioritised list of things to do and avoiding committing to precise times where possible. I've been presenting my roadmap in Powerpoint as a list of things we are doing in the next quarter, followed by aspirations for the following 6 months, getting progressively vague as we get further into the future.
The challenge is I've just been asked by my CIO to switch to using Jira Portfolio rather than Powerpoint for my roadmap. As far as I can tell from trying to use it and by reading articles and watching videos this will only work by changing all of our ways of working. For example it looks like it will need everything in the Roadmap to be refined to user story level and have a points estimate, and will then show what looks like a precise date by when it will complete. I pointed this out to the CIO who suggested that I just need more training.
Am I missing something?
Is there specific information the CIO is trying to gain from using Jira Portfolio that could be accommodated within your current process? or does the CIO just want a consistent report across products?
To me, changing your way of working for the sole purpose of fitting it into a new tool is bad practice. The tool should support your process not dictate it.
He seems to want us to use a tool for managing roadmaps and Jira Portfolio is the one that has been chosen because it's "best in class" and lots of other companies are using it.
He seems to want us to use a tool for managing roadmaps and Jira Portfolio is the one that has been chosen because it's "best in class" and lots of other companies are using it.
Who chose this?
Why? (saying "He seems" suggests you're not certain about what he wants to achieve)
A roadmap can supplement effective communication and transparency.
Was the decision made in consultation with the right people, in order to solve the problem effectively? If so, perhaps those individuals can advise the best way to proceed.
It seems that you perceive the introduction of a lot of waste by switching to this tool, along with a potential loss of transparency, as (if I understand you correctly) your current system lets you avoid providing false certainty.
Can your Scrum Master help you make these problems transparent (including, if necessary, to the CIO)?
Can you or your Scrum Team propose an alternative solution that addresses the concerns of the CIO?
I pointed this out to the CIO who suggested that I just need more training.
Interesting that his reasons for using the tool are around popularity and rating, and when presented with questions around the tool's functionality, his response is not to defend it, but to question your understanding of it.
Perhaps a discussion around the first Agile principle (Individuals and Interactions over Processes and Tools) is in order?
This situation reminds me a lot about Dilbert's boss.
He seems to want us to use a tool for managing roadmaps
Does the CIO respect your decision, as Product Owner, to model the product roadmap in PowerPoint?
Thanks for the responses. It seems I am not missing something and this has helped reinforce my position that this is the wrong tool to meet our needs. Unfortunately the CIO has a very strong personality and has marketed himself as an agile expert and that all the existing employees like me don't know what we are doing. Unfortunately my direct management know little about agile and software development so I'm struggling to fight my corner.
This is a tough one. You have a C-suite asking you to do something and the first instinct is to do it. And nobody would blame you for that. We all have a job to do.
With one of my clients, I was told that I needed to start using a tool (it's not well known) that the organization had invested a lot of money into acquiring licenses for and so that the leadership team could run reports off of it to monitor progress. I didn't have a choice.
The end result was that the multiple Development Teams spent a lot of time learning the tool. Time that could have been spent building increments. I spent days to learn to write custom code so that I could calculate weekday differences between dates. I could have done this in Excel in minutes.
However, when I work with clients who empower me and respect my decisions as a PM or PO, I use Excel and Powerpoint for almost everything. The tool is not what makes a team Scrum.