JIRA Agile has come a long way from the days of the GreenHopper plugin. It’s now pretty well integrated into JIRA and I’ve found it great for running an Agile workflow.
JIRA Agile supports both Scrum and Kanban boards so you can manage your tickets using whichever methodology you prefer but what if different parts of your team want or need to work in different ways? With JIRA Agile you can have multiple boards so tickets flow through different teams in different ways.
Maybe your developers are using Scrum with week long sprints. They want a standard Scrum board where they can take tickets from the To Do column, move them into In Progress when work starts and then to Done when complete.
But perhaps weekly sprints don’t really suit the planning workflow of your product team. They would prefer to use a Kanban approach of managing their work in progress.
Ideally we want to be able to create tickets on the product team’s board and move them into the developers’ board when they are at a suitable stage of readiness. By mapping statuses you can have a kind of combined Kanban/Scrum process.
Product Board
This is a Kanban board with 5 columns: Backlog, Requirements, Ready for development, Test and Ready for release. Each column is mapped to the following respective Statuses: IDEA, REQUIREMENTS, TO DO, RESOLVED and CLOSED. The IN PROGRESS status is left unmapped so tickets in this state will not show up on the board.
The product team can work on tickets in the Backlog and Requirements phases before moving them to the Ready for development column which will cause them to show up in the Development Scrum board (as we will see).
Once the developers have completed a ticket it can be moved into the RESOLVED state and it will then reappear on the Product board in the Test column. When the product owner is happy that the requirements have been met it can be moved to the Ready for release column.
Development Board
This is a Scrum board with the standard three columns: To Do, In Progress and Done. Some tickets may not need to be sent back to product for review and can be closed directly so the Done column has both RESOLVED and CLOSED statuses.
Scrum development board
When planning a sprint, the Development board will only show those tickets with a status of TO DO in the backlog. Tickets that are still being prepared by the product team (IDEA and REQUIREMENTS) are left unmapped so won’t show up until they are ready to be scheduled into a sprint. Once a ticket is moved into the RESOLVED state it will reappear on the Product board.
By combining Scrum and Kanban boards you can create a hybrid workflow that better suits the needs of the people actually working on the tickets. You don’t need to force everyone into a single way of working.
Great stuff. Any advice for how to break down larger stories into smaller ones within Jira? I’ve used a workflow very similar to this that adds in decomposition of stories in Kanban; you start with large, non-specific stories, and work them across the board to break them into smaller ones in preparation for scrum (production).
That does sound similar. As far as splitting up tasks goes, you can use subtasks in JIRA but personally, I prefer to stick with top-level tasks + links as required.
If you find you have a large, poorly defined ticket and you want to refine it in a scrum workflow maybe you could turn it into a task to define the actual smaller tickets to achieve the larger story.
Me Likey … Always looked into a way to combine these two workflows without having multiple projects.
Hi David,
Thanks for this write-up. We are trying to do something very similar. However, we are having some issues. I am wondering what the workflows look like for this to work? Can you please provide more details?
Thanks!
Ravindra, the JIRA workflows don’t really matter as long as the tickets are allowed to move between the statuses in the life cycle. It’s easier if tickets are allowed to be moved to any status from any status. The important part is mapping the statuses to the appropriate columns on your boards. I would suggest you decide the full life cycle of a ticket across all the boards and then map each status in that life cycle to the board you want it to appear on. So in this case, our tickets have the following status life cycle: IDEA -> REQUIREMENTS -> TODO -> IN PROGRESS -> RESOLVED -> CLOSED. You then map the appropriate statues to the appropriate boards and they will appear/disappear as they move through the life cycle.
Hi David, wanted to bounce something off you … I hate sub-tasks but we use them at work for our scrum work … I like this multi-board idea and could see it working for us … however, there is one use case that comes up from our management as to why they want to use sub-tasks and that is around the area of Test Prep and Testing across both automated testing and manual testing where there could be two different testers involved … what management want is to see that a tester is working on the Test Prep even whilst the Dev is doing their part – i.e. the tester isn’t waiting around …
I too haven’t been able to come up with a single main task with some type of multi-board, multi-user flow that would work … so was wondering if you have any wonderful insights into this …
The only argument I have come up with so far is that Test Prep should be done before dev as part of refinement and doing SPE work … but that hasn’t won management over to my side yet …
thanks
Kermie
Kermie, I’ve used subtasks for QA/testing tasks before. The main ticket is used for the development work and the subtask is for testing (and any other things that might be needed). This works pretty well and tightly links the QA work with the development work without having to remember to link the tickets manually. You can even close the main ticket and leave the subtasks open. I’m not sure if there is a limitation on closing JIRA sprints with tickets with open subtasks but it definitely works on a Kanban board.
[…] Kanban board is based on the London-based software developer David Keen’s Product board. Each column is mapped to the following respective Statuses (from left to right): idea, […]
David, Hello! Please tell me. How does your team assign tasks in Jira to a specific Developer or tester? The Assignee field is cleared when a task moves from backlog to development / from development to testing, or how? Please also explain the procedure by which you confirm the priority of the task.
@Paul: I don’t think the assignee is automatically changed by default but like pretty much everything in JIRA it’s customisable. You can change what happens when an issue transitions by editing your workflow and using Post Functions.
David, thank you for your response! I was interested in the process within the context of this article. I didn’t quite understand. When a task moves from the “Requirements” column to the “Ready for development” column, this task is visible on both boards (Product and Development) and the assignee for this task is still the author of the requirements, or in the “Ready for development” / “To Do” column, this task is with an empty assignment? Or, for example, when the developer resolves a task and this task is included in the “Test” column, the tester independently changes the assignment to itself? Does a vacant developer or tester assign a task to themselves, or does someone else do it for them? A team member with what role changes the assignment in a task when it moves from column to column between different performers for this task?
Yes, issues with the TO DO status will show up on both boards. It is then up to the team how they want to manage ticket assignment. You could leave it to be changed manually or perhaps you could use a workflow Post Function to remove the assignee when moving into the TO DO status. That way developers can grab new unassigned tickets from their “To Do” column.