Dual Track Scrum Summary

In my previous blogs of Dual Track Scrum (DTS), I cover the current expansion of Scrum to place more attention on building the right product through the means of a detailed, continuous discovery process tailored for developing better backlogs through multiple tools and techniques, such as story boards, feedback groups and surveys.  This is tracked through a separate discovery backlog similar in usage to the product backlog and feeds the results into improvements in not only the accuracy but the certainty that the right backlog is in place.

This overall discovery backlog (or also called the Opportunity Backlog) should address the pains of the target users, remedies to resolve/alleviated those pains, experiments to validate those remedies and any ideas and further options for product development.  It is very user centric, intended to identify those features that will delight users.  For instance, like many people I use my smart phone to deposit checks.  I used to get frustrated by having to deal with poor lighting or poor focus for the checks and would often have to take multiple pictures to get one to take.  Now, the Bank of America app came up with a version that turns on your phone’s light and auto sets the box so that when you have it at the right place, the app automatically takes the picture for you.  Viola!  Instant gratification!  This is the type of feature that I wanted, but hadn’t expressed.  Bank of America did a good job finding out a chief issue I had with electronic deposits…

I see two primary benefits with Dual Track Scrum:

1. Increased confidence and improvement of delivering the best product to increase end user adoption
2. improved handover of the product backlog to delivery

Note if your solution is strictly regulated and have little leverage to change or delivering in more of a waterfall fashion, this may seem like an improbable approach, but would say in my experience in for example the Health Care industry and Government, that the usability of regulated systems are in the most need of Dual Track Scrum.

With regards to the benefit of improved handover, it will directly address the issue many organizations have early in their Agile adoption and essentially break out requirements development, architecture and development/testing into an mini-waterfall process, which breaks one of the few core tenants of scrum of having fully tested, working software at the end of each sprint.  When the product backlog is unclear and backlog grooming isn’t sufficient, often delivery will slow down unless a more thorough approach such as DTS is substituted.

This often happens when a Product Owner is overwhelmed or simply not certain where to take the product next.  Often, I’ve seen Product Owner training for newer Product Owners unfamiliar with Scrum, and that would be a good supplement along with DTS.  Identifying and addressing insufficient Product Owner coverage early in delivery is critical for the successful implementation of DTS.

Cost and time are factors involved and often an approach such as Dual Track Scrum will be sacrificed or not even considered due to those limits.  Every situation is unique, but highly recommend considering using as much of DTS as possible even if “watered down” with the frequency of discovery sessions held is decreased.  Why?  Because cost and schedules will inevitably deliver an inferior product and assumptions with delivering your Minimum Viable Product should be validated frequently.

So if you aren’t sure your solution truly addresses your user’s needs or your scrum teams are frequently frustrated with extended user story elaboration and prolonged marathon Sprint Planning events due to nebulous product backlog items, then try Dual Track Scrum is worth trying and remember to fail (and learn) fast!