Workflow: Problem and solution

[joachim ramberg]

Hi,

We use product discovery to collect ideas, data regarding the problem domain and to prioritize collected ideas with a now, next later process.

We're struggling a bit with the "solution" part and where that process should be tracked. Our engineers have their own sprint board, a delivery ticked could be created there, a solution defined and then broken down into storys.

Does anyone else have som idéas or input?

[Carlos Garcia Navarro]

Hi @joachim ramberg ,

I recommend to look into the integration of JPD with Atlas and Jira Software. We use Atlas as our source of truth and repo for all documentation (e.g. PRDs in Google docs or Confluence pages). But if all your documentation is in Jira, you can integrate JPD directly with your Jira tickets.

[joachim ramberg]

My problem is not where to store the documentation regarding the solution but where to track the work. It's about the handover from JPD to the development/sprint board and what you hand over, just a problem or also a complete specified solution.

Should the work be done in JPD and a flag added to the idea when e.g. wireframes are done and UML has been created? Another solution would be to create an Epic in the development board with flags indicating when it's mature enough to be included in a sprint.

Does my thoughts make any sense? There are lots of guides regarding the discovery process and the sprint process but not so much regarding how they are connected in JIRA (what I know).

[Ivan Ferreira]

Hello @joachim ramberg

I think that @Carlos Garcia Navarro is right, you could use Atlas to create a project, describe the "solution" space there.

You could also use Confluence to describe the solution, and Epics linked to your Idea to track progress. In fact, you can use all of these options together.

If you want more inspiration, you could watch this video.

[Peter]

We use JPD literally as a Discovery project but, once a 'Idea' goes into Delivery (Development) our stakeholders can still track the progress in JPD.

This way we keep Jira for the more technical savy and JPD for stakeholders. We've set up a workflow including global automations that update the JPD items based on the Delivery progress.

It's a bit difficult to explain in short through text but I'd highly recommend to spent some dedicated time to workflows, automations and setup.

EDIT:

I don't know if this helps you, but I created a (very simplified) schematic visualization of how we build our process. The "circled" part is the part that is synced with the help of automations and workflows.

[James Traxler]

We use Jira Product Discovery and for each card there, we then create epics (and child stories) in Jira Software. In Jira Software, you can use boards and backlogs - Kanban or Scrum, etc.

> Our engineers have their own sprint board

@joachim ramberg, do you mean a physical board in the real world? Jira Software allows for the virtual equivalent of that.

[Peter]

@James Traxler yes we do the same, although we have a different issue hierarchy. It's very easy to track Jira Software issues in JPD if you spent some time setting it up correctly.

[joachim ramberg]

@Peter This gave me some ideas, thanks!

@James Traxler No, not a physical board, I want to keep it digital. I'll try to be more specific. When the team (engineers, product owner, ux) takes an idea (problem) from JPD and start working on a solution, where is this work done and where is it tracked?

For example, let's say that an Epic delivery ticket is created in the development jira board from an idea in JPD. Should the solution be defined in the Epic and is there a process where the Epic is transitioned from status "working on solution" to "solution is defined" so that it can be included in a sprint?

[Peter]

@joachim ramberg Have you tried asking those question to your teams? What works for them?

Or let me phrase it differently, do you know what problem you're trying to solve and for who? The biggest mistake we can make is assuming things, and if we assume that we know how the teams should structure their work we are setting ourselves up for possible failure.

I don't know how many teams there are within your organization or how they are currently structured but I'd highly suggest to start with some sort of an audit and try to understand the current situation, define the problem, and get feedback from the most important stakeholders in this; the teams themselves.

Start changing things in small increments and plan regular retrospectives.

[joachim ramberg]

Thanks for the input.

We're discussing this togheter and have some good ideas. We decided to browse around a bit to see if someone else had some good ideas that could inspire us further. I will take your input with me to our next session. :)