Just starting out after years of Jira use

[Kevin Gray]

Hi

I work for a large Market Research firm.  We are a monolith/waterfall company trying to make the transition to Agile.

In the past all the effort has been by the development teams and while this has had some impact, it is significantly blunted by failing to convert the business.

My team and I are attempting to turn that around and Product Discovery seems a great tool to enable the business to have a Window on the process.

I want to protect the business from large parts of Jira where there is too much technical complexity for them to survive.  I am hoping that the contributor role will give the business the opportunity to See Modern Roadmaps full of Sagas (ideas) and then push down into Jira for Epics and User Stories in a safe way without exposing them to Acceptance Criteria and technical tasks.

[Jan-Hendrik Spieth]

Welcome to the community @Kevin Gray :-)

It's impossible for me to say whether JPD is the right tool for you or not. JPD is a great tool indeed! Imho, it's aces for product managers and product owners who want to focus on pre-dev phases, who want to manage ideas for future dev task and the related feedback intake. JPD helps to juggle and settle on priorities.

JPD can be linked to Jira issues (so called "delivery tickets").You could sync dates via automation, and you can also sync with Atlas (which in turns maps to Jira epics).

And yes, JPD has a roadmap-like view. But in the spirit of JPD, these views are designed with a lot of "freedom" of configuration and use. Hard to say whether it can compete with (advanced) roadmaps in terms of definitive and binding timings ...

> See Modern Roadmaps full of Sagas (ideas) and then push down into Jira ... without exposing them to Acceptance Criteria and technical tasks.

I don't know how JPD would help with "not exposing" stakeholders to such Jira details. One thought about this: have you heard about Atlas, already? Maybe your dev stakeholders could be convinced to do project reporting using Atlas. JPD and/or your business owners would then consume that info, without having to dive into Jira.

[Jan-Hendrik Spieth]

One more thing: head of JPD product, Tanguy Crusson, explains things here quite well:
https://community.atlassian.com/t5/Jira-Product-Discovery-articles/The-relationship-between-Jira-Product-Discovery-Jira-Software/ba-p/2186837

If you are creating a product roadmap that you want to share with your CPO, CEO, business teams, support, sales, customer success: use Jira Product Discovery, and create views that explain the “why”

If you are creating a delivery plan that explains how you plan to sequence the work taking into account all constraints, in discussions with the people who care about the details for the “how” (e.g. engineering leadership): use Jira Software and Advanced Roadmaps.

Sounds like JPD could work for you, don't you think?

[Kevin Gray]

While timelines are important, the can be mitigated by scope.  In pulling away from waterfall, I find that any reference to timelines just ends up being a consideration that “everything will be delivered on a specific date” with no clear definition of everything.

Consequently I don’t like advanced roadmaps, they are too Gantt chart based for me.  The Roadmap format of Product Discovery is much better (Now, Next Later).

If I could have the majority of stakeholders only see Product Discovery content and Epics in Jira, I could avoid the issue of them getting too involved in the “How” when I need them to focus on the “What”.

I am a bit confused by one thing.  I have a product discovery roadmap which uses public descriptions so each card is small and snappy and the roadmap shows just the Now, Next, Later columns.  But I want a more detailed report on Now where the public description is replaced by a larger description (two paragraphs) and the cards are larger.

I don’t see how to reference that larger description in any of the reports I build.  Is it a field that I can include anywhere, or could short description be longer than 256 characters as it seems too similar to public description.

[Jan-Hendrik Spieth]

Sounds like JPD could work to your purpose, indeed. Nice!

I don’t see how to reference that larger description in any of the reports I build. Is it a field that I can include anywhere, or could short description be longer than 256 characters as it seems too similar to public description.

Afaik, cards can only show "short" text fields indeed. I can't say why, or whether the team has plans for changing that. But it makes sense to me, considering that the full description can contain heavy formatting, including tables etc.

Also, you cannot have different card layouts in different columns of the same board view.

Is there a way for you to break apart the info that you would want to have in a "more detailed report"? You would then use additional fields for that info, and place it on the cards. Maybe in a separate view, to not have all these fields show up in your main roadmap view.

[Kevin Gray]

Our ideas are not detailed, we restrain them to two to three paragraphs.  If there is complex supporting material (diagrams, case studies etc) we store them in Confluence.

Ideas are broken down into Epics and here we can provide more detail.  Where our ideas talk about broad concepts, Epics talk about one or two personae within those concepts.  This allows us to then break epics into user stories that are focused on individual personae.

A summary field with a 2500 character limit would work for me, 255 characters is just too short and too similar to the public description (they both have the same 255 character limit).

We already use a separate view for our “Now” board (compared to the roadmap view) I just can not find a way to deliver that longer description on that board.

[Nigel Budd (CV)]

Welcome @Kevin Gray  JPD is a wonderful tool and will no doubt give you the benefit you need, I just want to make sure that you are not trying to fix a process problem with a tool. 

What you described with the waterfall->Agile transformation requires changes to culture, ways-of-working/working practices and then tooling in that order.

The ability to see what's next, roadmaps, etc is powerful and provides transparency, but at the same time although agile teams do have plans, they don't necessarily follow them.  Be careful of creating wonderous roadmaps and then disappointing your stakeholders because your teams pivoted to something more valuable.  Agile teams delay commitments as much as possible.

[Kevin Gray]

I agree that tools don’t convert processes, but when you are looking for a cultural shift you often need ways of demonstrating the advantage of that shift.

A modern roadmap (Next, Next, Later) takes away the concept of time, enables a level of conversation we support where the business can provide ideas and impact statements and we can balance them with effort estimates and from this constantly review priorities.

Teams should always have plans and they should always expect them to change, even demand that they change.  If a plan (of the size of a roadmap) is completed without change, then there is a problem, if often indicates a lack of engagement.

If something is not right in a plan, then the business should want to change it, if the plan is really good they should be excited and want to change it.

We want to use this tool to aid our process, to give the business a window into development that does not need them to get oil on their hands as a result of touching the engine of development.

[Tanguy Crusson]

Thanks for the context @Kevin Gray and we'd love to hear how you go with your evaluation 👍