How left to right workflow splitting impacts the quality

How left to right workflow splitting impacts the quality

What is a workflow split?

Workflow splitting and creating stories is a key activity in agile product development. This activity results in sizable stories that are prioritized and sorted in iterations to ensure business value is delivered incrementally. Well defined end to end thin slices promote collaboration, incremental design, and better quality. On the other hand, poorly defined stories can lead to confusion and low confidence in the development process.

One of the ways to approach this activity is left to right workflow split. Although it seems the easiest and most obvious choice, it has a lot of side effects on team collaboration and product quality.

To understand more about left to right split, let us look at a use case. Assume your team is building a new feature in an e-commerce app. The feature is about providing users the ability to recharge their mobile numbers from the app.

A typical workflow for recharge would look like this journey.png

The easiest way to split such a workflow into sizable stories would be something like this split (5).png The stories created using this split would look something like this:

As user,

  • I should be able to view the recharge option on the app home
  • I can enter mobile number and view operator details
  • I can select a recharge plan

and so on...

Impact of left to right workflow splitting

This way of splitting workflow has many direct, immediate effects and some indirect, long-term effects on the team and the product. I have tried to list a few down based on my experience:

  • Delays discovery of unknowns It is impossible to know all variables and constraints of a complex system during the initial analysis. With this left to right split, Team has to wait till a very later stage in feature development to realize any unknowns and their impact. This delay can cause considerable rework if the discovery results in business or technical redesign.

  • Impacts testability The stories created with this split are seldom testable. As the output of the first step can be verified once the next step is built (or worse, at the last step), testing becomes a challenge. On the contrary, Thin end to end slices enable better exploratory testing and consequently, better product quality.

  • Creates a myopic view of the product The end to end product vision is only clear to a handful of people who worked on initial business or tech analysis. This can result in a technical design that lacks domain-specific design and redundant implementation.

  • Deters incremental design Another side effect of left to right workflow splitting is that it promotes Big Design Up Front, a relic from the waterfall era. The additional time spent in doing upfront design takes away the leverage to incrementally improve the design with each story or identify tech debts.

  • Limits collaboration and conversations Stories are usually prescriptive and limit collaboration between developers and business analysts/product owners. Focusing on a step in the workflow in an isolated manner leads to stories that sound like technical tasks, rather than user capability.

There are other long term side effects like a team that is missing domain context even after working on the product for a very long time, poor collaboration, and no excitement of working on product development.

How to approach

While researching for this blog, I came across this excellent article on story splitting, especially the story splitting flowchart can act as a handy guide.

Credits: Cover photo by Nick Fewings on Unsplash