Strategies for Executing Vertically Sliced Stories

At WWT, we believe our highest priority is to provide value to the customer (in alignment with their expectations). One way we do that is by breaking the work into thin, vertically sliced stories. A lot of work goes into breaking down the work in this way, but there is also a substantial amount of work and coordination required to execute on them in a team setting. Far too many teams fall victim to assuming vertically sliced stories require everyone to be well versed in all things for them to work. 

However, that is just one of the five strategies listed here. Specialization is a real thing and is very valuable. By specializing, we ensure that we make quality technical choices while reducing the cognitive load on the individuals making those choices. It does not detract from being able to execute on vertically sliced stories but does need to be harnessed in a good way so that it does not get in the way of successful teamwork.  

What do we mean by a thin, vertically sliced story? 

Thin vertically sliced stories are small end-to-end units of work that solve a specific problem. In 3-tier architecture, for example, this would include changes in the infrastructure, API and user interface. Each of these components may have a different language or skillset and therefore may benefit independently from specialization. 

Putting them all together in a thin vertical sliced story requires each specialty to work together. Implementing software in this vertical incremental fashion increases quality, allows the team to uncover surprises and blockers earlier in the process, helps relate value in work planned to stakeholders, enables early negotiation of capability before implementation details have been decided, enables shorter feedback loops and increases the agility of the team. This encourages team members to build something that provides incremental customer value rather than focusing on a particular layer of the "stack."   

Intended audience/disclaimer 

This document is primarily intended for agile teams trying to organize their work and their specializations around product objectives. Many teams don't have the luxury of experimenting with different approaches, and therefore the hope is these options may serve as a starting point given their constraints.  

The diagrams below attempt to visualize actual ramifications on people's time spent developing software within each of the strategies. There are several simplifications made regarding the amount of time people spend on each aspect of a story or work item. 

A deep dive into each strategy 

Strategy 1: Full stack development 

This seems to be the ideal strategy for building vertical slices. However, it also has some drawbacks. In this strategy, any person (or pair of people) has awareness and skill in all the areas of the system. That doesn't mean they are an expert; however, they are willing to learn and adapt to the needs of each aspect quickly and efficiently.    

Figure 1 (below) shows the lifecycle of each story for a typical web application. Each specialty employed is labeled and, as you might guess, could be accomplished by anyone on the team. A few things you'll notice about this picture is individuals contribute to multiple aspects of the story while pairing and then move to other stories via pair switches. The overall awareness and contribution of the team spans multiple aspects of development and includes everyone over time. This positions the team well for pivoting or changing key aspects of the system during each story and requires less upfront planning and coordination. 

Positive implications  

• Stories can be written agnostic of technical ramifications (e.g., not important at the planning stage what skills are needed to execute the work).
• Each team member (or pair) can work any story to completion, maximizing their utilization.

Drawbacks  

• Difficult to find the people that have had enough opportunity to refine all the skills needed.
• High cognitive load for team members (balancing the capabilities of each technology).
• Continued investment by individuals, project team and organization to maintain expertise in multiple tech stacks.
• May limit ability for team members to specialize in any given tech stack.

Strategy 2: Partial full stack  

In this strategy, a team is formed with people knowledgeable in one or many of the skills. However, some gaps still exist. When working on stories, most of the "hard" decisions are made by the experts in that technology. However, everyone on the team can contribute to the solution, leaving them capable of completing work without the local expert.    

In Figure 2 (below), you can see that partial full stack is still conducive to frequent pair switching and, in fact, should continue to do it because it enables the spreading of skills and expertise. However, in many of the pairs shown, you'll notice the pair's output is lower quality due to a lack of expertise. Over time the expertise will spread, and the frequency of the lower quality outcomes will reduce, transforming this team into one capable of the full-stack strategy.    

Positive implications  

• Over time, the gaps get filled and this team can operate in the full-stack strategy.
• Staffing flexibility: can staff teams with various levels of expertise in the given tech stacks.

Drawbacks  

• The potential short-term sacrifice of code quality and throughput.
• Increased technical planning for each story to benefit from the local expert (typically can be done in short bursts).
• May cause discomfort for the people with the larger gaps.

Strategy 3: Mob and focus  

This strategy is where the team recognizes the skill is spread out and each story will require contribution from different team members to be accomplished. To start the story, everyone on the team (or sub-team) comes together to get enough clarity on where the boundaries are so they can break up and work in parallel. We typically refer to the coming together of the team around a single story as "mobbing." These mobs can be short-lived and complete just enough work for everyone involved to know what to do next.    

In Figure 3 (below), you will notice that this strategy works well for small teams (or sub-teams) focused on one story at a time. You will also notice that some specialties on the team sit idle from time to time, waiting on the others. From a systems perspective, this is okay because by limiting work in progress (WIP), the system's flow is much better.  

Many times, teams that employ this strategy will have multiple sub-teams working from the same backlog. They may also stop pairing during the wait times or sacrifice pair programming altogether to limit the number of people sitting idle at once. Teams will often have non-vertical tasks or administrative work to fill the time while specialties are idle. They can also start planning to optimize future work without impacting system flow. The most difficult part of this strategy is recognizing and coordinating the start and end of a mob session. Teams will often determine cadence or establish key indicators for when to start or stop a mob session.  

Positive implications  

• The team can be formed with disparate skill sets.
• The team moves together through the work as one, keeping everyone on the same page and limiting work in progress (WIP).
• Sub-teams can be formed temporarily to parallelize work.

Drawbacks  

• Requires considerable amounts of team overlap and availability to enable "mob" sessions.
• Requires support and coordination to keep the mob on track and focused on the objective.
• Increased communication overhead to signal start, integration and completion of story work.
• Difficult to visualize the details of the work on a Kanban board (may need subtasks or sub-stories).

Strategy 4: Sub teams in constant collaboration  

This strategy requires the team to create sub-teams based on expertise. Each sub-team works with the others throughout the story lifecycle; however, most decisions are made independently. Teams employ several concrete artifacts to share context across the tech stacks, including process flow diagrams, API contracts, and one-off conversations. These artifacts help the team communicate requirements across the technical boundaries and stay aligned on the technical vision for the system. This way of working closely resembles horizontally sliced work. However, because the team shares common ceremonies and a common workspace, collaboration across technical boundaries flows much easier than if they were on separate teams.  

In Figure 4 (below), you'll notice this team has decided to maximize work in flight to utilize all the team members. This typically happens when one specialty has a long-running aspect of a story and the others need something to work on. The problem with that approach is each time another sub-team needs to make a change, they have to interrupt work, force a context switch and hash out the change with the other sub-team.    

This communication overhead and constant jumping context can cause decrease momentum and leave several things in progress at once. Like the mob and focus strategy, it can lead to idle time from specialties that have dependencies on others. This can be offset by overstaffing roles with the longest tasks and lowering the number of roles working on interdependent stories.  

Positive implications  

• Each team member deepens their understanding/skill of their piece of the system (specialization).
• Higher code quality in focused parts of the system.

Drawbacks  

• High communication overhead and context switching between stories.
• Potential wait time for other specialties to finish their work and verify integration.
• Few individuals can speak for the whole system, so planning and requirement gathering activities requires more people to achieve holistically.

Strategy 5: Story coordinator  

This strategy is a slight modification of sub-teams in constant collaboration. Rather than assuming each specialty will be available to do their part over the life of the story, one team member takes ownership of the story as it progresses through the development process. The owner regularly integrates and identifies gaps in each aspect, finding available experts to support the changes needed.  

In Figure 5 (below), you'll notice a very similar setup to sub-teams in constant collaboration, where the story has a primary driver. This person is responsible for ensuring the proper support is provided throughout the life of the story. They are constantly integrating changes from others and validating the software is moving forward for the story. This setup brings some order to the potential chaos that can arise in sub-teams in constant collaboration and ensure stories are progressing. Each story has a different coordinator, and therefore over time, understanding and ownership spread across the team.  

There is a mix of pairing and individual contribution throughout the lifecycle of the story to enabling higher quality implementation and specialization without sacrificing flow or vertically sliced stories. To mitigate the single point of failure to finish the story, the coordinator role can be changed during the life of the story with an intentional handoff and communication to the team.  

Positive implications

• Reduces cognitive load of team members trying to find what to work on next or deciding if a story is done.
• The coordinator can answer questions about the status of a story, identify risks across tech stacks and make sure everything is working together.
• The coordinator role can be rotated amongst specialties to spread the domain context evenly across the team.
• Stories can be started with limited availability of specialties.

Drawbacks  

• The coordinator is a single point of failure to "finish" a story.

Conclusion  

Each of these strategies has different costs and benefits. Teams should adjust based on expertise on the team, maturity of the team and maturity of the product.    

• Full stack development is ideal as it has the least amount of waste. However, it is far from realistic in a constantly growing company with a variety of skill levels.
• Partial full stack is next best in terms of reduced waste; however, it increases the learning burden of the team members, potentially reduces quality and can slow down progress which may not work well when trying to establish trust with the customer early in a project's lifecycle.
• Mob and focus work well for a team that can align schedules and are comfortable working in a large group, but it requires small teams and additional ceremonies and support to do well.
• Sub teams in constant collaboration enables deep skill and high quality at the cost of high communication overhead and frequent context switches.
• Story coordinator mixes the benefits of specialization with the alignment of user value while sharing the responsibility of driving stories forward across tech stacks.

Like many things in agile software development, there's no easy answer. No answer will work the same for every team. Rather, as teams, we should be willing to learn, inspect and adapt as our project needs change over time. Project teams can leverage each of these strategies at different points and even some of them simultaneously.