We are a small team of 4 software developers trying to use Scrum. We have a large project to start from scratch and we've hit a roadblock regarding slicing the project.

The project is a distributed system with many different components:

  • SQL Server database
  • A couple of web services implementing OAuth 2.0 (which we're rolling ourselves)
  • An audit web service
  • A FHIR web service (eventually)
  • Server-side modules (.NET assemblies)
  • A JavaScript based Single Page Application (SPA)
  • JavaScript based modules housed within the SPA
  • Our own in-house JavaScript framework for building the SPA modules

Our first PBI seems so simple: A user can log-in using their smartcard.

The problem now is using this user story to vertically slice, as just about all agile advice out there recommends: do we slice across the entire system?

If we do, it seems we're biting off a monumental amount; we would need to implement all of the OAuth behaviour including permission verification, most of the JS framework (HTTP handling, template and data-binding), the basics of the SPA and all the database structure and SQL logic that's required just to support this.

If we are to see each PBI as a deliverable unit that provides value to the user, there doesn't seem to be a way to break this down.

I've read so much on this yet all examples refer to much smaller and simpler applications.

Are we just being too rigid with our interpretation of Scrum?

  • It sounds like your team has discovered that choosing to include "A user can log-in using their smartcard" as part of the Sprint Backlog in their first Sprint would be a bad idea. That's good! So don't do that.
    – Roger
    Jun 20, 2019 at 16:30
  • Possibly related: softwareengineering.stackexchange.com/questions/103263/…
    – Roger
    Jun 20, 2019 at 16:55

3 Answers 3


You are gonna need it, but not immediately

So the point of vertical slicing is to take something like the database and say precisely, “I do not need the whole database right now.” So let’s validate your claim: do you need the database?

Let us be clear about what a database does: it distributes changes of state across several servers, and persists those changes when the server restarts. If you want plain persistence but no distribution, you can write to a local JSON file or so. If you want distribution but no persistence, you can have nodes broadcast messages to each other e.g. with ZeroMQ.

I don’t see anything in your first user story about any number of parallel servers, and I’m not sure I see anything in your first user story about any persistence; you might be able to tolerate the default in-memory behavior of “when we roll out a new version of the software everyone gets logged out and any changes they have made get reset.”

So you don’t need a database. You might need (if you have a list mapping some smartcard tokens to some sort of internal username) some static JSON file (not clear on whether it should be committed to repo or just a config file distributed over email/Slack and copied in as the last part of initialization; if you do not mind the data being saved to the repo then it can even be saved into one of your source files, no JSON parsing/file reading needed).

Similarly, do you need a big Javascript SPA? I don’t think so—you might need a card reader or an HTML form depending on whether it’s a hardware token displaying some digits or something more interesting.

Do you need a permissions structure? No, the only permission your user story covers is “is able to log in with a username and a smartcard associated with that username” and that is a global permission.

When you slice vertically you reduce each layer to only the subset of functionality which it needs to make the user story work. You are not trying to deliver one twentieth of the database and one twentieth of the permissions structure simply because you have twenty user stories and you are trying to deliver one of them. You may often find that in the early phases several of the layers are empty.

Use delayed functionality to get better business requirements

In fact you should desire this. I would strongly recommend that you delay creating the database as long as possible, which means, until you have real users who will get grumpy both about downtime and about their changes not being persisted over server restarts. There is a really important reason for this: top-down design is typically nearsighted. You want to be able before you eliminate your freedom to mess with data structures to get a real user to mess around with the business logic of your tool and tell you something like this:

“Oh no! You are assuming every Purchase Order has a Contract but that’s not correct, we actually have Prototypes which are experiments to try and get a Contract... We register purchase orders against them to build them, but they are not part of any Contract.”

“Yeah that wasn't part of our original spec. Do you have a common term that encompasses both Prototypes and Contracts so that I can show you a list of _____ and then a column that says "type=Prototype" vs "type=Contract"? What would that list be called?”

“Oh yeah, we just call them all projects.”

And then you rewrite your internal data structure so that purchase orders belong to a project, which might have type=Prototype or type=Contract, unless you get enough differences between them that you need a Prototype table and a Contract table that are foreign-keyed-to by the Project.

The point is that if you don’t delay the creation of the database until you get this feedback, then under pressure you will start to get a very warty database:

“Uh, why are these Contracts having all of these null values? Did we just forget to make them NOT NULL?”

“Maybe. Do they have a number for their prototype_id?”


“Well see what the database calls a contract is actually what the UI calls a project, because when we started we thought that all projects were contracts, but they are not, some are prototypes. So either all of the contract columns need to be null and the prototype_id needs to be not-null or else the prototype_id needs to be not-null and the contract columns need to be null.”

People think best when they can interact with a system. Especially people who are giving you requirements. The point of Agile is that traditional software design is sort of like asking a committee who knows nothing about clothing to write a specification about what sort of clothes they want to wear and then we will produce those clothes exactly to that specification and then if they are unhappy with how they fit they are free to not wear them or to produce follow-up documents anticipating how they change. An Agile shop is trying to instead produce a set of successive tailored approximations that at all times fit the client exactly but do not look right. So they start with “ok, we will throw a sheet over your head” and receive the feedback “OK but I cannot see through the sheet and also it is the wrong color for what I am going for.” New sheet in a better color with a hole in it. “No, it needs sleeves and a hood.” And so forth.

You can deliberately delay getting important bits of functionality right, because you might be misunderstanding something like the “color” that requires a considerable amount of rework from scratch. This happens all the time with database structures.

  • Thanks for your answer. Say we don't implement the SPA and JS framework initially, at what point do we implement them? The user doesn't care, but we as developers would very much like a framework to speed up the UI development.
    – Lee
    Jun 21, 2019 at 6:47
  • 2
    @Lee: You implement those when some stakeholder (could be the developers) starts demanding it. If you ask an end-user they might not even want that whole login/permission business. Jun 21, 2019 at 8:32
  • @Lee What Bart said. Keep in mind also that developers can do a lot with UIs that are not SPAs, for example, a shared list of Postman requests that everyone can turn back to.
    – CR Drost
    Jun 21, 2019 at 12:34

The short answer is: no, do not slice through all of it unless the thing you are doing actually goes through all of it, then keep it limited in scope.

The idea of the vertical slice was to get away from backlog items like "Design database tables for customers." If you are using backlog items that provide value from the customer's perspective and it only touches a few of them, that's fine.

Also, start with simple architectures. You almost certainly don't need all of those things to support your first few backlog items. I am frequently surprised how far into a software project I can deliver value without things like a database. If we build the application to be loosely coupled code or, better yet, highly decoupled code, adding in extra components later when we need them isn't too much work.


When you have a distributed system with many components, you can run into this kind of issue. I've found that a good starting point is the idea of technical enablement. You have a top level expression of a need, but you can create other Product Backlog Items that can enable that. Each one should be able to be designed, built, tested, and delivered independently. Perhaps, alone, they don't satisfy the final user need, but they allow you to plan the work and ensure that you have what you need.

It gets even better if these technical enablement pieces of work can unblock several different user-facing Product Backlog Items. Depending on what the various Product Backlog Items are, you may be able to find creative ways to slice up the technical enablement in certain ("lower level") components to enable a swath of Product Backlog Items while ensuring that they are reasonably sized, scoped, and deliverable.

Depending on the tooling that you are using to manage your Product Backlog, you may be able to set relationships and links between the work to identify that a technical enablement item "blocks" other work or set dependencies appropriately. This can help in planning and scheduling the work, making sure that everything required is done and delivered when its needed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.