Slicing and planning work
Offline stock counts is about two months of work for the Store app team. This lesson shows you how to cut it into thin slices that each work on a real scanner, put honest ranges on the estimate, count the days your team really has, and find the risks early with short spikes. You finish with a delivery plan you can defend to Imran and Ken.
By the end you can
- Cut a big feature into vertical slices that each deliver something, starting with a walking skeleton
- Choose a way to split: by workflow step, happy path first, by data or by store
- Give estimates as ranges using three-point estimates and a forecast from throughput
- Work out a sprint's real capacity after leave, on-call, meetings and the focus factor
- Name the risks that could move the plan and answer the biggest ones with time-boxed spikes
The everyday picture
A family is cooking dinner for 40 guests at a festival. One cousin suggests a plan: first chop the vegetables for every dish, then cook all the rice, then make all the sauces, then plate everything at the end. It sounds efficient. But nothing is ready to eat until the last hour, nobody tastes anything until it is too late to fix, and if the gas runs out at hour three, the guests get five half-finished dishes and no dinner.
The aunt who has done this twenty times works differently. She makes one complete dish first, start to finish, and tastes it. Then the next. If time runs short, the guests still eat three finished dishes. When someone asks how long it will take, she says "three to four hours, unless the market is out of fish", which is a range with the main risk named. And she counts her helpers honestly: four people in the kitchen, but one of them leaves for an hour to collect the grandparents. That is this whole lesson: finish thin slices one at a time, give ranges, name the risk, and count the help you really have.
Vertical slices and the walking skeleton
The Store app has layers: the screens on the scanner, storage on the device, a sync queue, and the NestJS API with PostgreSQL behind it. The natural plan for offline counts builds them one at a time: the API and tables first, then sync, then device storage, then the screens. Each engineer owns a layer, and it feels efficient. It has three problems. Nothing works for a user until the last layer lands, so Ama cannot try anything for two months. The hardest bugs live where the layers meet, and you meet all of them in the final weeks, when there is no time left. And if priorities change halfway, you own four layers that are 80% done and no feature at all.
A vertical slice cuts through every layer for one narrow behaviour. In 2003 Bill Wake compared a user story to a layered cake and asked teams to slice it vertically, so every piece holds a little of each layer. His INVEST checklist says a good story is Independent, Negotiable, Valuable, Estimable, Small and Testable. As a tech lead you can turn that into three practical questions for every slice:
- Can someone do something new when it is done? Tara in the demo, or Ama in her store, on a real scanner.
- Can it go to production? Behind a feature flag if it is not ready for everyone, but merged, released and running.
- Is it small? About 1 to 5 ideal days. Bigger slices hide surprises; split them again.
The first slice has a name. Alistair Cockburn calls it a walking skeleton: a tiny version of the system that does one small thing end to end and connects the main parts, even if each part is crude. For offline counts it is this: one staff member counts one aisle with Wi-Fi off, the count is saved on the scanner, and when Wi-Fi comes back it reaches the API and appears in the back office. No review screen, no fresh items, no conflict rules, one test store. Ugly is fine. The skeleton proves that the design from Technical vision and design docs works on the real hardware, and it gives you your first real number for how fast the team moves on this code. Every later slice adds behaviour to a path that already works.
Keep the skeleton's code and grow it. That is the difference from a spike (later in this lesson), whose code you throw away.
Quick check
Which of these is a vertical slice of offline counts?
Only the third goes through every layer and lets a user do something new on a real scanner. The tables and the sync API are layers with a task name; they deliver nothing until the other layers exist. Designing every screen first is useful input for Leila's work, but it is still one layer.