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

Axel Joester_03w24b

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)