Vertical vs. horizontal slicing of requirements

Email address:

Leave this field empty if you're human:

Today I will talk about one of the main capabilities of a good Product Owner (PO), one of the core aspects of agile working: slicing requirements horizontally instead of vertically. It sounds so easy but is so hard to do in practice. It is, in my view, one of the main features of agile that unlocks team productivity.

In the past years it has been en vogue for a company to want to work agile or use scrum. Often times what happens is putting post its everywhere and building a board or nowadays the company buys a Jira license. Then, exactly the same work that was being done before is posted there. Stand-ups with the team lead are held where every team member dutifully gives their status update. And voila, the company is now agile.

Don’t get me wrong, making the work visible is very important and can have great benefits. The same goes for creating a platform where the team talks about progress and problems. They are both features of an agile mindset as well. At the very least, there shouldn’t be any unforeseen things happening. However, to truly get the benefits of agile one needs to change the way to think about work packages and specifically how they and the associated requirements are defined. What does this mean?

Let´s assume there is some sort of solution with a set of requirements that needs to be developed. In order to do that, the following steps need to be gone through: data analysis, writing code, and quality testing.

The traditional way to set up the work packages would be exactly like that: first data analysis, then writing code, then quality testing. They are sliced vertically and usually done sequentially.

There are several downsides to this approach

• One might notice a mistake you did in the analysis only in the final quality testing
• It usually takes fairly long until value is created
• Customer feedback is only received after everything is done

Those points combined can mean that the team spends months working on a feature only to find in the very end that customers actually don´t want or need it. This is obviously not very effective and leads to frustration.

In comes the horizontal slice. Instead of doing it the way explained above the goal is to define work packages or user stories in such a way that they include – in our example – data analysis, writing code, and quality testing all in one. To make the work packages manageable, requirements need to be split in such a way that value for customers is created. Additionally, task needs to be so small that it can be done in a fairly short amount of time, ideally by a single person without dependencies to others. This is hard! If done right though, the benefits are massive:

• Extremely fast delivery of value to the customer
• Creates the opportunity to test assumptions about customer´s needs very quickly
• Errors are found very quickly
• Often times it also leads to more ownership of the tasks by the team

The above sounds great in theory but there are some points that need to be addressed in practice. The most important might be team composition and team skills. To stay with the example above, it is very likely that not all team members have experience in all three of data analysis, writing code, and quality testing. There are several ways to address this.

One can request support from other teams or other team members that have the skills or experience necessary. In this case the full responsibility stays with the original assignee of the task. He or she is then supported and hopefully in the mid to long term learns how to do it fully by themselves.

In case very specific knowledge is necessary that cannot be taught or shown easily, one can split the work packages horizontally but ensure that they are done by different people from the same team in the same sprint. This is not ideal, but ensuring that they are done in one sprint still provides most of the benefits of full-scale horizontal slicing.

Lastly, I personally have often encouraged team members to give it a shot, even if the task is not their core expertise and they hadn´t done it before. I have made the experience that people tend to be pretty smart at coming up with solutions even if they don´t formally have the skills to do so. In this case the end result is probably not the 100% solution but it generally provides a perfectly sufficient result. (In case parts of the work are completely unknown, I highly recommend to timebox those parts.)

In case you are unsure whether you have applied a horizontal or vertical slice you can use the following three questions to check. If the answer is yes to all questions, you probably sliced the requirements horizontally.

1. If this work package is fulfilled, do I have something new I can show to customers?
2. Can this be done in one short period of time or within one sprint?
3. Can it be done by one person (or by the team) without dependencies to others?

Overall, horizontal slicing of requirements has some very obvious upsides and no real downsides. Besides stakeholder management, and understanding customer needs, this is the third main task of a PO, usually greatly aided by a Scrum Master. Doing this well separates, in my view, the truly exceptional Scrum Masters and Product Owners.

Smartly slicing requirements unlucks great productivity gains within the agile framework and is an absolute necessity for incrementally improving a product. However, I am not sure there are any drawbacks to also using it within any other product development method. Thus, next time you are defining work packages or stories, I highly recommend you take a step back and really consider if there isn´t a way to cut the requirements horizontally.