Dual Track Scrum in JIRA
In the past year we have been transforming our way of working, from a roadmap-based product backlog to OKR-based initiatives which are validated before being added to the product backlog.
The process of validating ideas is called “Discovery” and the implementation and productisation of these ideas is called “Delivery”.
In this post I’d like to describe how we use Jira in conjunction with Dual Track Scrum to manage both the Discovery and Delivery tracks.
Here at Gumtree we work in two-week Sprint cycles. The challenge we faced was how to integrate Discovery work, which inherently is not time-boxed and involves UX, PM, analysts and engineers, with the implementation/Delivery work, which is incremental and fits into two-week cycles.
Objective:
One Jira board for Discovery and Delivery
We’ve tried using two separate boards, however we did not find it effective in terms of visibility of all the work undertaken by the squad, and the distinction between the two types of activities felt superficial. Hence combining both work streams / tracks in one view was deemed essential.
Challenges:
Capturing both Discovery and Delivery work in one board is tricky as both have different workflows
Delivery tickets follow a standard flow:
Discovery tickets have a different flow:
Solution: We decided to map states from each flow on the board’s column configuration. This should work regardless to how many states you have in either flow.
*note the filters for Deliverables/Ideas in case you wish to inspect one view in isolation
Discovery work doesn’t necessarily fit in two-week Sprints
Discovery work initially usually involves a UX person as well as product manager/owner. The research that goes into defining an experiment to validate a hypothesis (idea) cannot be easily estimated; while it can be time-boxed, we found that we get maximum benefit letting it run its natural course. For that reason, we don’t plan for experiment definition and validation to fit in a single sprint. Furthermore, the followup work of defining the experiment and creating the UX too doesn’t fit nicely within a sprint.
Solution: Treating the UX work as a constant stream of work, likeable to a Kanban system allowed us to effectively capture two-week scrum delivery work as well as Kanban discovery work.
Should Discovery work count towards velocity?
Given we’ve established discovery work is not part of a sprint, the discovery tickets are not estimated. UX work is not included in the team’s capacity planning and doesn’t count towards velocity.
Solution: Discovery work is not estimated and assigned story-points and doesn’t count towards velocity
If Discovery involves coding activities (e.g. setting up an experiment) should it count towards velocity then?
Discovery works that requires setting up experiment with actual coding (not Optimizely setup alone) is queued up for the next sprint and is estimated just like any other deliverable.
Solution: Discovery work that requires coding is estimated and counts towards velocity
“Ready for Development” definition for Discovery tickets
Discovery tickets which require coding to enable an experiment are “ready for development” once the experiment has been sufficiently defined and included designs and impact analysis (where applicable)
Finally, Discovery tickets which have been successfully validated are linked to a Delivery ticket to implement the idea.
Any questions, please leave a comment.
