One Workflow going through three boards: Good idea or bad idea?

[Axel Joester]

Hello everybody,

our external consultants help us to improve our practices as a development team.

We used to have a pretty simple jira scrum board.

The consultants advise us to create two additional boards

• a requirements-kanban-board for requirement gathering and refinement until they are "sprint-ready"
• an acceptance-kanban-board for review of developed changes.

Both kanban boards are shared with productowner and stakeholders.

I think that is a good idea.

I immediately saw two possible approaches:

• (1) additional issuetypes "requirement" and "acceptance", with their own workflows, automatically managed by their respective kanban-board. In requirement-done we build a linked development issue. In development-done we build a linked acceptance-issue. This is done using transitions, that don't alter status, but start a groovy script, cloning the issue into the issuetype of the next board.
• (2) One giant workflow, flowing the issue through all three boards in order:
  • requirement (kanban)
  • development (scrum)
  • acceptance (kanban)

My team urged me to try the approach 2. Seemed to be easier, less issues to handle.

I tried to object, seeing approach 2 as a mis-use of jira, with all kind of problems resulting. I failed to convince, as I couldn't pin-point the problems to expect.

So, I try to develop using approach 2.

Steps so far:

Built a big workflow, built the boards.

Normally, jira-boards manage a simplified workflow automatically, directly resulting from the statuses it displays. I could not use this feature, had to handcraft a workflow with three partitions of statuses for each board, all statuses of one partition having transitions to all statuses of the same partition, and then single transitions from the last status of one board to the first status of the next. No joy, but managable.

I filtered the boards, only including issues in statuses belonging to the respective board.

Issues reaching their last column in requirements-board are transitionend to scrum-backlog.

When a scrum-sprint is done, finished issues are transitioned to the acceptance-board, manually by jql/bulk-change (I plan to automate this lateron by a scriptrunner-listener reacting to sprint-done-event.)

The first real problem I stumbled into was the resolution-field: Every issue can have only one resolution, so I would have to set resolution in the last column of the development-board, as sprint-logic depends very much on it.

So the following acceptance kanban-board has to deal, right from its first column, with issues already resolved. Kanban-boards do hide long-resolved issues, 2 weeks by default. Of course we don't want to hide the issues here, as from the view of the acceptance-process, they are not resolved at all. But if we switch hiding off altogether, every issue is displayed, even the ones, that are "really" long done.

We could of course just clear issue-resolution on entering the acceptance-board, but this messes up scrum-statistics of past sprints in the development board.

I feel more problems coming, but still can't really point them out specifically.

So I'd like to ask:

• Has anyone of you worked with a similar kind of setup?
• Are there other reasons to see approach 2 as a mis-use, which should be avoided?
• Or is approach 2 feasible and what should I consider going further?

Thanks for reading!

Background: We use Jira Server. We have adaptavist scriptrunner and can automate repetitious tasks if needed.

Best regards
Axel

[Nic Brough -Adaptavist-]

This is a superb question, as it highlights all the pains of trying to do cross team issues within larger groups of people.

So to frame my essay:  you've only described two approaches, but there are really three

1. Create one issue, changing its type and/or project when it needs to go to another team (part of your option 1)
2. Create one issue, with a monolithic segmented workflow (your option 2
3. Create many issues, one for each team

So, to get one thing sorted first - take out option 1 and nuke it from orbit.  There are no circumstances under which it is right to make fundamental changes to the structure of an issue as part of its lifecycle.  You wouldn't turn a house into herd of cows just because someone moved out of it!

Options 2 and 3 are worth discussing further. 

To try to keep it short, you've done option 2 right and run straight into the main problem with it.  One team's "done" is not another teams "done".  You can make it work on boards by including all status after a team's main done in their done column (If you have a row of 5 status, where team A sees status 3 as done, team B sees it as 4 and team C as 5, then team A's done column should contain status 3, 4 and 5, Team b's needs 4 and 5, and team C just status 5)

But, non-board stuff in Jira runs off "it's done if the resolution is set".  You've tried to handle it by having the team's done be resolved, but that means the following teams are in the odd position of having a pile of issues that they need to deal with that Jira sees as resolved, and hence tends not to report on.  It's actually better to explain to your requirement and development teams that, because of they way they want to work, Jira is going to report their done issues as resolved, because it can only truly resolve it when acceptance says so.  (This isn't so bad, it recognises that Acceptance may have questions for the earlier teams anyway, and shows that the team's work is not truly complete, if if they've done what they can)

My last option might be worth a look. 

At the most basic level, you have 1 project per team, and one working board (people can use others, meh, there's just one you agree on as the team board).

As you've got Scriptrunner, this is a doddle.   When an issue moves to "done" (meaning "ready for the next team to take over"), create a new issue in the next team's project. Link it back to the original, copy any details that matter to the new team (maybe) and let them run with that.

This gives you some weaknesses in reporting because you've now got three issues for one thing that needs doing, but they're not to hard to deal with (one simple trick - a scripted field that echoes the requirement issue that ended up spawning the other two, for example)

[Nic Brough -Adaptavist-]

If there's one thing to pick on, it's the "trick" of "include all later status in the flow after this team's done", it works really well, for exactly the reasons you say!  The rare time someone might spot something in "done" that needs to go back, and they can't because it's with another team - I don't think that's a problem, most people will open the issue for a more detailed look and quickly realise it's with someone else so they can start that conversation!

My third option is very similar to your first one, as they're both very clear on which team things are with , but it avoids the nightmare of "move issue to another project or type"

It still works for a "10 project, but combined board" scenario, but you do have to plan out where things should go a bit more carefully.  The three project scenario I went with was deliberately simplified to requirement / development / acceptance so that I could concentrate on the benefits and implementation.  It was highly simplified so I didn't have to talk about it a lot ;-) 

Having 10 projects really is no problem, it just means your script can't say "requirement done, so I create the next issue in the development project", you need to delve into the logic of where the next issue should be in a bit more detail, to build the right routing.  But you could base it on anything.

[Phill Fox]

One additional little trick I frequently use with complex linear workflows is the escape route transition. With this I use the transition from "All statuses" to every sensible return point in the workflow but also add a condition to restrict the visibility of this transition to only people in the role of Project Lead. This means when an issue is inadvertently progressed too far the project lead is still able to return it back to the correct place in the workflow but more importantly they have visibility of the action. (Do not forget to clear resolutions as well if transitioning to a status prior to resolution.)

[Axel Joester]

Oh, I forgot, my option 1 really doesn't change the structure of the original issue. I would build a new linked issue with a different issuetype. This is just triggered by a transition that does not change the triggering issue at all.

I completely agree that changing an issue in some fundamental way as part of its lifecycle is an idea to be nuked hard.

[Axel Joester]

Hello Nic,

ah, good idea to let the statuses of later boards appear in the last column of the previous. As long as there is no direct transition to those statuses, the board won't display drop-zones for these, so there would not be a risk a team could accidentally set an issue to a status it should not. I didnt think of that! But on the other hand, it might be a bit irritating seeing an issue in the last column and not being able to move it to the left...

Your option 3 is interesting. Resembles my option 1 somewhat, though you would rather split projects where I would prefer not to: I didn't mention that our scrum-board already bundles 10 Jira-software-projects all sharing config, and I'd rather like to have requirements/acceptance of one projects issues all cleanly in the same project. On the other hand, permissions in a dedicated requirements/acceptance-project for each software-project could be more cleanly organizable, as each software-project may have different stakeholders. I'll have to think about it.

Good idea to echo the requirement via scripted field. Those are really useful, adaptavist!

Thank you very much for your ideas!

Best regards
Axel