A key tenet of agile development is the creation of a potentially shippable product increment at the conclusion of sprint. The industry seems to have settled on a sprint duration — the cadence — of less than a month, of 30 days. From a marketer’s perspective, invariably, the fast-paced dynamics of modern day marketplace will force the building of a certain solution by a certain time. Thus, usually, several sprints worth of incremental output would be needed to satisfy any given perceived market need of a substantial nature. The industry has also settled on the nomenclature of a Minimum Viable Product (MVP), to refer to such a multi-sprint output.

In an agile world, it becomes imperative to build the software in such a way that each sprint is able to progress inexorably towards the MVP. Another dimension of complexity comes about because software is invariably delivered as a service over a cloud — public, private or hybrid. Thus, in addition to the software product that consists of the core of the logic, it is also necessary to line up the necessary tools useful for day-to-day operations & maintenance, the so-called DevOps tools. Therefore, at the end of each sprint, the incremental output needs to have not only the newly-developed software, but also the attendant DevOps tools.

[See Also: Server WebSocket: Old Fashion in New Style]

Vertical Slices

What has all of the foregoing to do with vertical slicing, particularly when much has been written already?

Let us briefly examine vertical slicing through a simple model of a modern application, described by Peter Green of Adobe, in a blog post, Splitting stories into small, vertical slices. If each user story is defined in a vertical fashion, the team can indeed provide demonstration when the user is story is ‘Done’, either to a client or a Product Owner, the result of the ‘Done’.

In my work as a Scrum Master and Agile Coach, I have come across — even in 2016 — user stories that fail to encompass a vertical slice through the target MVP system. Consider a user story that focuses merely on the visual design of a set of user screens. Granted, there needs to be consistency among the screens, etc., and a certain focus is needed to ensure such consistency. However, if all a story accomplishes is a bunch of agreed-upon screens when it is ‘Done’, it fails to deliver value, in terms of working software, for the sprint. (There is another disadvantage to defining user stories in a non-vertical manner: What will the team do when the non-vertical story has been completed? It introduces all kinds of scheduling problems, very reminiscent of waterfall times).

In a guest post with Mountain Goat Software, Peter Green of Adobe describes a Minimum Viable Product (MVP) exercise where, without the advantages of vertical slicing, it almost seemed impossible to come up with an MVP definition deliverable within the given time constraint.

[See Also: Leveraging Swagger to Manage and Harmonize Rest APIs]

While defining user stories in the increasingly cloud-centric world, as we already noted, we will typically need to address two classes of users: End user and the DevOps user.

The responsibility of ensuring vertical slice creation is with the Product Owner although, in full agile spirit, each member of the team needs to take part in ensuring vertical slice creation.

Any note about vertical slicing would not be complete without mentioning the idea of emergent design. Defining vertical slices, while it produces sprintly software before an MVP is available, may sometimes result in an interim design that makes use of tentative implementation which, subsequently, will need to be addressed. In other words, we need to let the design emerge to its ultimate state: The so-called idea of Emergent Design while addressing the evolution in terms of Technical Debt. A brief discussion of these concepts can be seen in Emergent Design and the Intelligent Product Owner.

Everything you need to know about outsourcing technology developmentAccess a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.

Introduction Package

Source: zymr

This article was authored by K Ramesh Babu, who is the Chief Agile Officer at Zymr.


Leave a Reply

© 2019, Zymr, Inc. All Rights Reserved.| LEGAL DISCLAIMER | PRIVACY POLICY | COOKIE POLICY