Should I have a separate idea for 'design' work?

[James Conway]

I'm just getting started setting up my JPD project and want to get the community's thoughts on best practice. 

The context is that we are early in the product lifecycle and have some large and complex features to design and implement through this year. The rough plan is:

Feature A: Design Q2, implement Q3
Feature B: Design Q3, implement Q4
Feature C or D (TBD by more discovery): Design Q4, implement 2025Q1

Then there will inevitably be smaller features and improvements we need our designer to work on.

How would you approach this? Thanks in advance :) 

[Stacy Smith · Accepted solution]

@James Conway   our approach for this would be a single JPD Idea for the project (feature) with linked Epics as the delivery of the parts.  So in your scenario you might have an Epic for the Design, then an Epic for the Implementation if you want to roadmap those 'departments' separately.  The benefit of one JPD Idea is keeping all of the project parts in a tight Idea container.

In our environment we approach the project as full-stack, meaning we don't have separate JPD Ideas to segregate technical departments (research, design, infra, coding).   

[Troy Moore]

I would create a new idea for each feature and track the timeline status of each idea via the built in 'Roadmap' field within JPD. I would also suggest creating subsequent roadmap JPD views to facilitate discussion around your 'Now' and 'Next' items. For instance, In Q3 Feature A will be in the 'Now' view and Feature B will be in the 'Next' view. I've found that separation of Discovery/Design vs. Delivery has been most helpful. Creating checkpoints to ensure the movement from Next to Now is also a useful idea. Example: For Feature C, you may want to have a check field called 'Design Doc'. If the design doc is not provided, do not move to now.

The 'Now' and 'Next' views within JPD can be tailored for each type of work needed, therefore allowing you to track some fields when reviewing the 'Now' vs. the 'Next'. Whatever fields aren't relevant for 'Next' may be relevant and made viewable for 'Now' and vice-versa.

[Andy Keohane]

Given those timescales, I think I'd structure it as you have there, 3 separate ideas with each one having one or more delivery epics and each epic containing the tasks or stories that need to be delivered.  Whether you split the epics by 'department' (UX design, architecture, development etc.) or by functional increment is up to you of course, but that should give you a decent handle on it