Divide Scrum Work More Efficiently with Vertical Slicing

Developing complex custom software applications is difficult, even in ideal circumstances. In a Scrum workflow, it is desirable to have as few stories as possible in progress at any given time. This helps to maximize throughput and to ensure that multiple stories aren’t partially completed in a given sprint without points to show.

Unfortunately, dividing up work efficiently can be a real challenge.

Risks of Dividing by Expertise

If a given story is to be split up in an efficient manner, it is tempting and even desirable to break it up according to areas of expertise. While having individual devs operating in their areas of maximum expertise can result in a high velocity, it can also be a big detriment to project health in the long term.

In a multi-tiered project, devoting devs to given layers in order to tackle a single feature can expedite completion of the pieces of a feature. A very common problem, though, is that, without careful planning and constant communication/review of completed work, you may run into integration headaches. This may not only take extra time to work through. In extreme cases, it may lead to extensive rework to make pieces fit.

The Downside of Creating Silos

Short-term optimization is very alluring, but it can lead to long-term inefficiencies. While it may be the best call to tackle a high-priority story with a tight deadline, practicing this form of labor division can create silos of knowledge and expertise, causing critical long-term inefficiencies.

Relying on a single developer with the highest level of expertise to tackle certain domains or layers of an application can also degrade long-term performance. A given feature is best tackled by multiple developers who are significantly knowledgeable about the entire stack and domain areas. This allows architectures to be formulated and executed efficiently. When silos are created, the quality of design and the corresponding execution can be thwarted by disconnects in understanding and strategy.

Having developers focus on the same pieces of an application for months or years at a time can also lead to isolation and boredom, likely resulting in missed details and thwarting creativity and enjoyment. As developers, we need to be challenged to keep our creative edge, and also to sharpen our skills of crushing large and complex problems.

Using Vertical Slicing for Success

An alternative to throwing many developers at a single feature is to break down large stories into smaller vertical slices. Vertical slices are about defining stories or tasks that individually provide all of the pieces for a full user-facing feature. Completion of a vertical feature slice involves adding/changing any code necessary in any of the application layers in order to actually complete a given feature.

Breaking larger stories down in this fashion allows the pieces to be developed independently and in a way that doesn’t create unfulfilled dependencies between layers. This gives the developers a wider breadth of experience in a project codebase, and it is a much healthier strategy for long-term success. Operating this way creates great diversification in a team, and it prevents the risk of taking a major productivity hit if a single developer leaves the team.

Though relying on developers who are inexperienced in a given area or language may cause some short-term hits in productivity, this strategy will set your team up for long-term success. It fosters a better team spirit, and better understanding of how to tackle new tasks as they come up. This all leads to more happiness, confidence, and creativity—key components of success for individual projects and developers in general.


  • Teams new to this approach complain that their vertical stories are too big for one sprint. And as we know that leads to lots of problems. Sometimes they insist on breaking up those big ones into component stories in order to get stories small enough for one sprint. They can be especially adamant when a vertical story requires a lot of foundation work in order to support the exposed user-facing capability.

    Rather than doing that, and bringing all the old problems back, a solution often used to good effect is the “tracer bullet”. That is a story where the user-facing capability is present but extremely rudimentary, so most of the story’s work is in the lower layers that are required to permit the first bit of user-facing capability.

    By postponing most of the UX work in this way, the story usually can be reduced in size enough to make it deliverable in one sprint, while still being vertical and getting all those benefits.

    All kinds of lower layer issues can be uncovered early with a tracer bullet, without incurring the investment cost of most of the UX work or the integration risk of component stories. It introduces a kind of technical debt, but the payoff in risk reduction is worth that cost. A surprisingly frequent result is that the requirements change based on the experience building the foundation… often changing (and even sometimes simplifying) the UX before any investment in it has been made.

  • Comments are closed.