We have been hearing the concept of 'vertical slicing' a lot lately. I think we have been doing a better job of creating smaller, more well-defined stories. When I was searching for info on vertical slicing, no one has been defining how large their systems were. For example, I saw one where Adobe contracted with mountain goat software to come up with a solution for getting features done vertically, even across several teams.
For more info on me, my background was with a larger corporation where teams were responsible for certain back-end systems, and we'd have to work over at least two sprints to get things done as a 'feature'-- there was the back-end work for the other system, and the integration work for our system. My point is that the frame of reference for vertical slicing in that company was somewhat at the 'project' level. A project can be a complete set of databases, backend server, background services, message queuing/processing, etc., but it was well defined around a central company project.
Our client-facing web app, for example, had multiple DBs of its own, it pulled from several data stores that other projects dumped information into, had batch apps that ran nightly, read and wrote from and to several message queues to send emails to customers, etc. Even with all of that, all the 'deliverable features' were vertical within the 'project'. The stack usually went: client -> web server -> database or web service.
For any given feature lately, we have to make changes to the following:
- Data work in a popular cloud-based CRM (there is a separate team for this)
- on-site database work, usually only 2 or 3 of the DBs are touched for a given feature 3.Two separate API service apps - one is in maintenance mode until all the apps can be upgraded to the new API. Both integrate with 1. and 2. above.
- Multiple clients that connect to the old API
- Multiple clients that connect to the new API (some connect to both)
- The old API calls the new API for some stuff so we only integrate major logic in one place as we are waiting for the clients to be updated.
- We have multiple processes run as service apps or batch apps on app servers.
* note that each web client also has its own back-end server, not shown in the diagram.
frame of reference for attacking this and creating user stories is similar to my experience at the previous company, mainly because of the following factors:
- Team size (2-3)
- User Story size (8 pts)
- Sprint length
- varying client-side technologies
- I feel that a user story should be able to be tackled by a single person in order to track completion more easily. In some cases, the work could be split, but it'd likely be at the horizontal level at that point ("Can you do the database work while he does the back-end logic, and I'll do the UI?").
I think the biggest thing that we're worried about is the 8 points. Management is flexible on this, but not very. It's hard when story points are 2-3 hours. What I've proposed is that we have a 'project' frame of reference. I believe that getting the feature implemented in the new API, for example, is a good accomplishment in 8-13 points. This can include the database layer, etc., so it's still a vertical slice within that ecosystem, but we're horizontally slicing the systems.
After that, each client app can be its own story, as they each have their own client and server code, as well as the API integration.
We (devs) typically try to use one [TFS] feature for the main back-end systems (business logic) and one [TFS] feature for client apps (integrators of the back-end systems). We track large-scale 'features' requested by the business as Initiatives or Epics when they touch a wide range of applications, and for those we could have one feature per client app. We could tackle 2-3 features in a sprint like this, and it's easier for us to track as devs vs. trying to have one story to accomplish this, which spans multiple service implementations and web apps.
Are there pros or cons to either approach, and do you have any additional experiences with vertical slicing across a large chain of applications/services?