No other responsibility is more stressful for an Agile Practitioner than ensuring proper Product Backlog Items statement so they are independent, negotiable, valuable, estimable, small and testable (see Bill Wake’s INVEST). The quality of the items is the difference between a backlog that is in line with client’s wishes and fully understood by the Agile Software Development Team, and a vague list of doubts, misunderstandings and wrong assumptions.
Traditional project management and Application Development processes were originally based on the old engineering approach of tackling big and complex problems by dividing the work that has to be done at architectural layers. This is a horizontal way of analysis, to have requirements stated as horizontal slices of the solution.
Horizontal Slice
It is in sync with waterfall software development, where you have specialized teams for each of the architectural layers. So there will be an infrastructure team for the hardware that has to do all the work so data base guys will begin to create the entire data structure and once that’s completed, the backend developers jump into getting things done on the server-side so the frontend team can start working.
We all know the limitations of this approach:
- Reduces client feedback loops that eliminate any opportunity for inspection and adaptation until most of the work has already ended.
- It increases integration problems because it waits to the very end to mix all the components and hope for the best.
- It magnifies the uncertainty curve for the project there are not frequent revisions.
Each item of the work that is planned using this path must be described as a “horizontal slice”. So instead of having a comprehensive list of features wished by the client stated in a way that all parties involved understand them, you would have a list of highly technically specified tasks that nobody is going to be able to read. Forget about work transparency and clients or stakeholders staying awake in meetings.
Most clients won’t have the technical expertise to even require such tasks, which in the best scenario are only going to be fully understood by the specific team that executes them and that pattern is repeated on every layer.
Worst case scenario? There’s not a single team member who understands the requirement properly, so the risk for underachieving at the end of the project is HUGE.
Vertical Slice
Agile Software Development is a whole different animal, especially scrum, the go-to framework for most agile teams. This is all about empiricism inspection, adaptation, and transparency; way shorter feedback loops and client’s collaboration in the project.
There’s a Product Owner who is responsible for describing the client’s requirements in a way that is in a language that any stakeholder can understand and that properly describes the work that the Development Team must execute. The usual way to accomplish this is by using user stories that don’t intend to describe requirements but make everyone talk about them and understand what must be done when the time is right (watch Mike Cohn talk about user stories).
Here is where the vertical slice technique comes in place since every user story must refer to a feature in the product, understandable by anyone involved in the project and considering underlying architectural layouts. So, for the first user story you would have something like:
“As an admin user I want to be prompted with a notification every time there’s a purchase so I can contact the customer via email”.
The main feature here would be the one about purchase notifications but to get things done during the sprint the development team is going to be working on the frontend for the notification prompt, on the backend for the logic implied in the sync between this and the customer’s purchase process, and finally, there would also be some work to be done on the database side. In short, for every user story defined in the backlog, there would also be work required on every architectural layout which means that no team member is going to be on hold while others are working, everyone is working at the same time on a piece of the solution that can also be deployed and tested right after is done to get feedback immediately.
In short, this technique is going to make your job much easier as an agile practitioner.
Now you ask: How am I supposed to vertical slice my project requirements? There are some great strategies out there, you should take a look at the following:
- Peter Green proposes 4 steps.
- Chris Sims has a similar 4 steps approach.
- Christiaan Verwijs has 8 strategies.
- And Richard Lawrence offers 9 patterns.
At a glance, engineering is the discipline of dividing complex problems into simpler smaller parts to tackle them one at a time, all you have to do is resist the temptation of doing that division in architectural layers. Never forget to INVEST all requirements.
The Success Formula: Agile, Nearshore, and strong Automation.
Our Recommendation is to hire a Nearshore partner (that means a time zone +/- 3 hours, cultural proximity and proficiency in English) that works its software engineering process using an Agile Software Development methodology with strong Automation like Jira and Scrumwise for the User Stories and Acceptance Test combined with GitHub for traceable releases, Zoom and Slack for team’s communications, among others tools for QA Testing and Continuous Delivery.
This Formula will accelerate the total production rate of the combined team in terms of reducing written communications and documentation, handle requirements and releases, minimize delays in QA Testing and manage daily meetings.
Teravision Technologies is the right partner in Agile for any complex Information System, web application development, mobile app development, software testing and more. Using either fixed-scope projects or dedicated software development team.
