Backlog Construction - Board for Requirements

Thiago Cunha

So I was observing how weel the process is going with the developers side but not as much for the product owners. 

 

So I had this idea where I could also create a workflow for the backlog construction process. I designed a workflow like demand > discovery > prototype > Validation > Refinement > Ready. I think this should help the PO's to organize better and we can predict if we're going to have enough requirements for the next sprint. 

 

So I was wondering, what is the best way to do this in Jira.

Idea 1: have multiple boards with diferent workflow for the active sprint, for example: Board 1 - Sprint - Board 2 - Future Sprint-

 

Idea 2: Just simply creat a another project where all of the PO's from all of the squads would use. Also the developers and techlead would have acess if needed. 

 

Idea 3: Just add the collums do the today workflow in a way that requirements from this sprint and for the future will be together. 

 

So, do you guys have a board for backlog construction in your workflow? Does it work? If so how do you do it in jira? 

 

 

Bill Sheboy

Hi @Thiago Cunha 

I believe you have listed many of the methods teams use; the details are in how to use Jira to help manage and visualize those.  "Taking it to the team" can help figure out what they believe could be tried and improved.  At this time, one limitation is whether you are using company-managed projects or team-managed projects; team-managed don't have multiple boards yet, I believe.

1. One board, concept to cash: one kanban board with the entire workflow.  Implemented the same as it sounds in Jira, without a backlog.
2. Separate discovery and a delivery boards.  One backlog, two boards.  When discovery work completes, you could "reset" issues back to the backlog for delivery selection, or use separate and more detailed issues for delivery.
3. Backlog and board.  One backlog where discovery and refinement occurs, and a board for delivery.  This is a typical scrum layout for Jira usage, and has the limitation that discovery/refinement workflow is not represented.
4. Multiple backlogs and boards, supporting different silo-driven approaches for product, delivery, service, operations teams, etc.
5. Mix and match...
6. And as the volume/complexity grow, any of 1-4... could use multiple Jira projects to represent different products, projects (like in PMI-lingo), value streams, etc.

Jira is very configurable, and I suspect that if you describe how your teams work someone in the community can offer how they are supporting that approach with Jira.

Best regards,

Bill