Dual Track Scrum Tools and Techniques, Part 2

Within Scrum, a product backlog is used for tracking prioritized development requirements as normally determined by the product owner.  In Dual Track Scrum, it is recommend to use a separate backlog for the Discovery track.  Essentially, the discovery track backlog will “feed” into the product delivery backlog.  Discovery tracks would include techniques such as User Research/Validation, story mapping, building and testing personas, engaging in “what if” scenarios on design, creating minimum ceremony prototypes and tracking Key Performance Indicators.

Consider the opportunity canvas from my last blog (https://agilemichaeldougherty.wordpress.com/2015/08/24/dual-track-scrum-tools-and-techniques/), which covers the pains, remedies, experiments, ideas and options with continuously validating the right solution is being developed.  From that opportunity canvas, user research helps determine what your target audience wants is fully understood.  This can be done via user feedback groups, surveys, usability tests (like A/B Testing) tracking metrics and reaching out directly to the user base.  Now, if you don’t have an existing product, reaching out directly to the user base may be your only option to get direct and candid feedback of product ideas.

Story mapping is a core Agile principle similar to story boarding in the film industry where each step within a solution are created visually through a low fidelity interface in a top down approach.  This is intended to be very flexible so that story can be quickly added and removed as new ideas come up.  At a physical level, a board with post-its work really well.  There are many tools to map digitally and have a preference for FeatureMap and CardBoard, but recommend you research what is best for your needs.  A good article on story mapping is at http://www.thoughtworks.com/insights/blog/story-mapping-visual-way-building-product-backlog.

When it comes to delivering the right solution, knowing your audience down to a specific persona should not be overlooked.  Build model and “edge” audiences to determine all variances of users.  If your target audience are women between 18 and 35 for a cosmetic app, you should still consider including men of different ages that may have a reason to use the app as well.  These personas should be fed into your story board and real users should be found that closely match these personas to validate assumptions and clarify new ideas.

Holding “what if” brainstorming sessions on what and how to build will help promote continuous improvement and recommend using mind maps as tools to visually expand on asking questions on what the ideal solution would do if time, budget and feasibility were not a limitation.

Quick and repeated visualization is a key to delivering a continuously improving solution.  Through low fidelity prototypes, quick assessment and validation can be used for all the previous steps as a visual aid.  As the discovery matures, these prototypes should mature too, becoming higher in fidelity as features are validated as the right ones to build.  New ideas are then introduced at minimum visualization and mature as they are accepted or disappear if rejected.

Finally, to follow the old adage of “What gets tracked, gets done”, Key Performance Indicators should be determined for validating the benefit of discovery.  Ensuring that new features are being modified and improved is necessary.  If the discovery does not create enough change or no change at all, then the discovery track is broken and must be addressed.  Metrics such as the rate of changes, the projected benefits of those changes and the resulting improvements with user adoption (and funding) are critical to tracking.

I’ve heard of cases where daily refinement sessions to properly flesh out the user stories for the delivery backlog, would be held right after the daily stand up, but recommend this be held on an “as needed” basis, which may be every other day, weekly or even less.  However, a regular cadence should be set for each technique to best track progress.  The outputs of the discovery sessions should be incorporated into the product backlog and transitioned to the sprint backlog by the start of a new sprint.

In my next blog, I shall cover my overall opinion of Dual Track Scrum and it’s usage in today’s solution focused industry.

Advertisements

Dual Track Scrum Tools and Techniques

To continue on Dual Track Scrum (DTS), please note at this juncture, I have not put any of these steps fully in practice and so they are purely from a theoretical perspective, although I am aware that DTS pundits such as Aaron Sanders has implemented these tools and techniques within multiple organizations.

To recap, Dual Track Scrum provides an expanded Agile framework for Product discovery that aligns with Product delivery.  This expands on the rather thin structure around backlog grooming and story boarding thus putting more effort and rigor into that process to continuously validate the right solution is being development.

Remember the tenants of discovery are building valuable, usable and feasible solutions.

There are several tools and techniques available with DTS and will cover the overall current state approach with the opportunity canvas.

The opportunity canvas brings detailed clarity of the current product landscape, in an effort to better define what features are the most important in any given solution.  They include:

  • Documenting any assumptions that would be a product killer if proven false.  Be very open and honest on determining these and can be as simple as “Google releases a similar product”.
  • A clear description of the problems the solution is addressing as well as the solution description itself.  This should be high level from an end user perspective as part of a product theme that is frequently tweaked.
  • Describe the users and customers that currently experience the problem.  Who are they?  What is an example persona?  How much does it impact them?
  • How these problems are addressed today?  There is always an existing process and there are usually more than one.  What are they and how much time / effort do they take?
  • How this solution will provide the users new value/improvements?  Time savings?  Cost savings?  Entertainment?  What else?
  • How to measure whether and how much the users would adopt this solution.  Look at what metrics will make a difference in knowing the predicted adoption rates.
  • Determine the adoption strategy to bring the most users on board.  This should be based on the previous opportunity backlog answers to derive the best strategy.
  • Determine any business problems in building and delivering this solution.  Find out the challenges with delivery, marketing, sales, support, etc. with the solution.
  • Identify and measure any changes in business performance metrics for releasing this solution.  Your business will change with the release of this solution and therefore the measurement of success must factor in this solution.
  • The budget must always be considered on how much can be built for a Minimum Viable Product and when revenue must come in to continue building and expanding the product.

I will cover further tools and techniques in my next blog.  A big “hats off” to Aaron Sanders for much of this material.

Dual Track Scrum continued

In my last blog, the topic of Dual-Track Scrum (DTS) was brought up.  That was for my initial impressions.  Now this blog covers a deeper dive.  The ideas behind DTS started with Marty Cagan in 2009 and expanded to being supported by Jeff Patton and Aaron Sanders, among others.

Essentially, Dual-Track Scrum follows core Scrum for the delivery path and expands on the idea of a parallel discovery path for better and more thorough product development.

This parallel discovery path has three core tenants.  The results of the discovery path should be:

  1. Valuable – This is determined by the Product Owner and the UX/UI Expert and validated by the end user community as something they would want.  Discovery of valuable features is critical to successful delivery
  2. Usable – This is determined by the UX/UI Expert and the Development Lead.  The interface for the feature should be built in such a manner than it is as simple as possible that the users love, adhering to Lund’s Usability Maxims (see http://www.simonwhatley.co.uk/lunds-expert-ratings-of-usability-maxims)
  3. Feasible – This is determined by the Product Owner and the Development Lead.  Dream big, but make certain it’s something that can be done with the technology available.

The discovery process has been expanded into more details as opposed to backlog grooming.  In Scrum, backlog grooming is an exercise for the Product Owner to work with the Scrum Master and key team members to validate the backlog priority and prepare for upcoming Sprints.  Per the book “Scrum Essentials” by Kenneth Rubin, this is done on an “as needed” basis.

In Dual Track Scrum, these are broken into regular scheduled meetings similar to Sprint Planning and Review meetings and should be held in a similar cadence.  Attendees include the Product Owner, Business Analysts (as needed), the UX/UI lead, the Development Lead and the Scrum Master (optional).

These discovery sessions go into much further detail of discovery that brings the end user feedback along with tools and techniques to bring out more accuracy and detail on ensure the right product is being built and evolved over time.  Arguably, most critical component of delivering software is not whether it was built on time, on budget or even in defined scope, but whether the end users like and even delight in it, to expand its usage far beyond original expectations, which leads to growth and success.

In my next blog, I will review the tools and techniques for the discovery path.

User Stories Expanded

This is a continuation of my July 16th blog on User Stories.

User stories in the simplest form is documentation for Agile delivery.  However, User stories are not necessarily requirements.  There is a fine line between a user story and a requirement and difficult to often distinguish.

A user story is different than the “must have” requirement in that although it provides the instructions on who, what and why something is being built, a user story should be a transparent conversation between the product owner or user/Business Analyst and the delivery team.

It follows the “Card,Conversation,Confirmation” model brought forward by Kent Beck when Extreme Programming was intorduced into the IT world.  User Stories should focus more on making sure the two groups understand each other on the delivery and less on say following a template or having a well written document.  The conversation should lead to building the right solution (at least the right solution understood at that time) instead of just following instructions in a document like a recipe.​  When you create something new, recipes are meant for documenting what has been made, but not the acting the actual process of getting to that recipe.​

As a final point, the relationship between the Product Owner, the team and Scrum Master must be built on trust and frequent communication in order to form and evolve excellent user stories.  Otherwise, user stories will miss key information and lead to unnecessary rework.

Building Good User Stories

In developing accurate requirements and derive accurate estimates from client engagements, user stories are increasingly becoming the de facto standard for documenting.

Simple in concept, but difficult to master, user stories have this basic format:

As a <actor/user>, I can/want <what> so that <why>

The “how” is kept out, since that is what the delivery team should figure out.  You shouldn’t need as a client know how the car was built as much as how to properly run and maintain it.

However, the trouble can be with getting the right level of granularity to the user stories so no “big surprises” come out weeks or months after the initial requirements gathering process.  There is an art to recognize this and doesn’t follow any template or “silver bullet”.  There are many ways to help define user stories and going to the appropriate level of detail should include recognizing asking questions even in the details for say highlighting key facts of a product.  It can be done in one form of highlighting but upon further research, there can be multiple ways with a “wish list” or favorite, commonly chosen favorites by others with similiar tastes or similiar products.​

That’s when the devil is in the details and has to be handled through many questions and sufficient planning.