Many developers have the practice of splitting their tasks into layers. This approach makes a lot of sense when we are coding a new software feature. However, in the project plan perspective, if we split our backlog into software layers, the outcomes of the backlog items won’t deliver any working software to the end user, and consequently, their problems will remain until all the layers are done.
Regarding most of the Agile frameworks, such as Scrum, the idea is to always deliver a piece of working software to the end user with the highest value by the end of each interaction/sprint. However, even if we deliver the whole database structure with the best possible design, this will be useless to the end user unless we provide a user-friendly way to handle the data.
The most common way to write a software requirement in the Agile world is through User Stories, so let’s see a good and a bad example of how to split these items to deliver real value:
- (BAD): As a developer, I want to define the whole structure of our database so that I can start coding new features.
- (GOOD): As a Student, I want to be able to check my attendance online by myself, so that I don’t need always to ask my teacher to do this for me.
The examples above are deliberately simple to demonstrate this concept. Look at the following image to keep it clear:
Applying the vertical slice to your backlog is something that takes time and practice. When teams start doing this, they might have some items that are too big to be attacked in one sprint, for example, and the art of splitting those big value items to smaller ones that are still valuable to the user is the exciting part. Once the team is managing this technique with mastery, good outcomes start to appear, and the results are faster, generating better inputs from the Product Owners to prioritize the items on the backlog more precisely.
Written by Daniel Bastos – Business Analyst and Scrum Master – Linkedin