nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is JPD for features only? Should bugs be included or no?

David_ij6mqo

Our team is looking to restructure our Jira projects to be more organized and efficient. I definitely want to implement JPD, but I'm not sure if bugs should be funneled into this project or not.

One thought is to create a separate project just for our bugs. On the surface, it doesn't seem like bugs belong in JPD but would love some other opinions.

Accepted answers

All comments

Amanda Barber

How are you tracking bugs now? It doesn't feel like bugs belong in JPD to me either, but I guess I see JPD as more of a feature-prioritization project for my product team. If you're tracking bugs elsewhere already, then I think it could be useful to keep them separate unless you need one place to see everything that's being planned/worked on - in which case, I still think that a different project that brings in tickets from multiple sources might be better. I'm super curious to hear what others think!

joachim ramberg_2o8afx

I agree, bugs should not exist in JPD.

Tere Pile

My opinion: JPD not for bugs. Really not even for 'Developers' per say. Ideas managed by product, w/developers for contributing information. JPD is new and has some cool stuff, but 'work' should be done in delivery projects be it software or work management and bugs are 'work'

Ivan Ferreira_31ou4g

I will vote for having bugs in JPD. I recommend a "Work Type" field and include Bugs. I propose this because:

If you have bug fixes that are part of your next release, that should be in your roadmap
If you have engineers working on bugs, that is capacity that you don't have
If you have engineers working on bugs, that is money that you spend
You want to make all these visible to the stakeholders
You can easily create views to filter by job type

If you don't track features, enhancement, tech debt reduction, and bug fixes, in the same place, you will get the whole picture incomplete.

But! That is just my opinion.

Karie Price

I look forward to following this discussion - great question! We're just beginning to prepare to use JPD and getting off spreadsheets and I've been wondering this too. Since many bugs are items our leadership wants to see on the roadmap, I am considering adding those there so we have a singular view of prioritization and what's coming. Not all bugs would end up there though - but maybe an issue that represents a group of bugs? Or bigger bugs?

Karie Price

This is where I'm leaning too, but I think it's a balance on what level of detail. So I'm considering groupings of bugs or major bugs only, but I hear you that anything that impacts capacity should be reflected so there is better visibility into all of the work to do.

Dison Martin

I do include a summary of bugs in JPD via my high-level, timeline view of the Roadmap (my highest level view of the roadmap that only Execs/Stakeholders utilize). Today, we actually tie all completed bugs to a quarterly Epic called something like "2024 Q1 Bugs" in Jira Software. I then tie that epic to my JPD bugs card in the delivery section for that quarter. It helps me in the following ways:

Serves as s a reminder to me that bugs will inevitably take a portion of Engineering's time/capacity every quarter.
Serves as a reminder to Stakeholders that bugs require capacity from Engineering.
Ease of access and traceability.
Gives me a sense of throughput or burn rate for bugs to help plan from a capacity perspective for future quarters.

In summary, more of a planning placeholder, but not where the work for bugs actually happens. Hope that helps! Will be following this thread to see how others are planning for bugs! Great question.

John Magro_v04h31

I recently rolled this out with our team with great success and I couldn't agree more with @Tere Pile below "JPD not for bugs. Really not even for 'Developers' per say. Ideas managed by product, w/developers for contributing information."

While this solution might not work for every team, Id argue it the workflow that makes the most sense given we want a siloed workspace as PM's/PM teams to work on fully-baking ideas/features/etc before moving into an Engr board to make ready for dev. Again, another opinion, but a bug, depending on its impact and prio really should go straight into the Engr board to properly prio and triage. Additionally, they typically dont need to have as much discovery/design/development which is where JPD thrives.

For additional context, we were using Canny prior as an Ideas Board w/ lots of limitations. Weve since then leveraged Canny as a mass company and customer ideas "hopper" where we then prio > move the ideas we want to focus on into JPD > develop them until ready to handoff to dev (PRD, Figma designs, insights, etc) > Move/Create tickets into Jira Engr Board. This allows Engr to stay heads down and not get bogged down with another place to look at info, it gives our Product team the place to do our work, and keeps out any unnecessary noise from other teams.

Hope this helps! Good luck! JPD is a great tool w/ lots of exciting things coming down the pipeline it seems to support our needs as PMs/PM teams

Karie Price

^ This is exactly what I was thinking. Glad to hear that someone else is successfully using a similar approach.

Mike Morper_9dqbot

I do not think bugs should be included in JPD.

We have found JPD to be a great resource for documenting new jobs to be done and/or capabilities for our products. JPD is a great federated "dashboard" where my team links in supporting evidence (insights from interviews, mocks), including smoke signals from our sales org, where we link in Salesforce opportunities that may require the capability/enhancement to earn the business.

New value ceremony

From an operational viewpoint, my team holds a weekly session with our SEs (representing our field sales org) to review a View we have set up in JPD to assess Ideas in consideration and how they should be prioritized based on their insights from our presales efforts. This greatly assists the PM team with a great perspective on the business opportunity (Salesforce Opps must be linked in to make the discussion).

Once we have clarity on success, we create a delivery ticket (Epic) in the appropriate Jira project and move on from there.

Bug ceremony

Similarly, we do the same with our CS/Support org. However this is focused on the bug side of the equation. Our support org uses Zendesk, and tickets are promoted directly into Jira. During this ceremony, we strictly review the Jira items, and score then accordingly. No need for any of that to find its way into JPD. In my mind, that's taking a step backwards.

Nic Brough -Adaptavist-

We do the same - bugs go on the roadmap because we need to be able to see everything the teams need to address in one place.

JPD is great for building roadmaps and planning future improvements, but "fixing this bug" is part of the planning.

As Dison says, a bug issue in itself may not be the place the bug investigation and fixing happens, that's up to the developers as to how they break it all down (or just have a single issue to work on), but it is very useful to see it on the roadmaps. If nothing else, you get to see "we don't have the resources to get this new thing done by X" and "we need to spend time fixing this bug before we can look at implementing new feature Y".

James Traxler_5dt1px

We have a card per release for the bugfixes in that release, e.g. V2.20 Bugfixes.
More of an exercise in ensuring visibility.

Nic Brough -Adaptavist-

I think it's good to show bugs in JPD, but not manage them directly in it unless it's really easy (which it rarely is)

As @Karie Price says, there's a balance on level of detail. I want to see and plan bug fixing in JPD, so that everyone can see what is happening and can plan properly, but the detail of the bug should be a story, or set of stories, within a development project that the customers probably do not need to see.

Jonathan Blackburn_zgmfj4

Personally, if working in quarter prioritization, I might have one ticket to capture the work allocation and the main themes in terms of defects and quality. I'd then rate/score according to the relative severity and impact of them.

Using that plus prior capacity analysis (% of engineer capacity spent on different types of work - feature/defect/improvements/tech debt/learning) I bring it to discuss with my stakeholders and team on what we want to prioritize against features, improvement and tech debt in view of our current goals.

I don't like to be too prescriptive with bugs but we need flexibility to deal with some urgent ones as they arrive. It feels like overkill to define and track them at ticket level both in JPD and JSW.

Heather Ford_8c6w70

We do the same and it works well. We essentially look at bugs as items to be prioritized and managed within the backlog. Whereas items in JPD are the ideas that will likely get broken down into epics that create a body of work to complete as part of the backlog/next sprint.

Heather Ford_8c6w70

Agree.

Hari Shankar S

I do not think bugs should be included in JPD.

The Purpose of JPD is for the Project Intake/idea and product teams capture and prioritize ideas and align everyone with product roadmaps - Views can be managed at one go including the Delivery progress.

Wherein bugs (Can be during development phase - Post development bugs like UAT/Regression/SIT or etc.) - all these should be managed in the same Jira board/Projects where team is working over feature/US.

If it a production defect even that should be managed the same board/Project from which team is responsible to address the defect.

henceforth JPD is not a place for bugs.

Kyrstin Dittenhafer-Swartz

We were just talking about possibly using JPD to organize our defects process today - super happy to find this thread!

I'd actually be curious to know how the JPD team manages defects with JPD. I've already picked up on the fact they use JPD to manage Ideas for JPD itself (how meta). So, are they also using JPD to manage defects with JPD itself, too? If so, how? If not, what is their alternative process?

Kyrstin Dittenhafer-Swartz

For further context -

I see additional comments on this thread about JPD not being for bugs/defect b/c they're "work" and work should be in delivery.

While I agree, we're looking at JPD for defects as a way to visualize the "roadmap" and "status" of defects to stakeholders outside of development.

Hari Shankar S

This can be managed in your regular Jira Projects - As I mentioned you before The Purpose of JPD is for the Project Intake/idea and product teams capture and prioritize ideas and align everyone with product roadmaps - Views can be managed at one go including the Delivery progress.

Also you are having too many thoughts in one place - may be you should start segregating and use necessary Atlassian tools like JPD , JSM , Jira for your team , each tools have their own unique purpose . Just go through portal .

kyle bell

This is really where my head is as well. I don't want to 'manage' bugs in JPD, but when we're tracking features that are being delivered in upcoming releases on our roadmap, major bugs might be the main reason we get stuck holding a release.

In such a case, showing all features 100% done but the release not being finished just creates questions from stakeholders that aren't in the weeds with us.

I know I'm late to this thread, but does anyone know if progress has been made on this? I know I can do it manually, but I'd love to do this via automated rules (bugs, release target, priority, etc.)

Welcome!

It looks like you're new here. Sign in or register to get started.