Skip to content

Walking skeleton

Introduction#

When building a new product or feature, a walking skeleton is the thinnest possible implementation of a whole capability, built, deployed, and tested end to end. It is production-quality code running in a live environment, perhaps with gated access, and it is the start of the real system rather than a demo or proof of concept.

Starting by implementing a walking skeleton maximises early learning and reduces risk. It gets working software into production early, so that the architecture, delivery pipeline, and our understanding of what users need are all tested against reality while the system is still small and it’s easy to change direction.

This page explains what a walking skeleton is, how it differs from a prototype, how to build one in practice, and why it is worth doing.

What a walking skeleton is#

Alistair Cockburn

A walking skeleton is “a tiny implementation of the system that performs a small end-to-end function.”

A walking skeleton has these characteristics:

  • It’s usable. Although it may be far from a finished product, it already implements real functionality that a user can interact with.
  • It proves integrations. It links together the main architectural components, including the ones outside our control, such as identity providers and third-party APIs.
  • It is production-quality and it is kept. The code meets the definition of done and is not thrown away. Future iterations build on this working system, adding flesh to the bones.

Because it is production-quality and it is live, a walking skeleton is potentially usable from very early on, for a small subset of user needs.

Building the skeleton helps us validate our understanding of user needs and the best way to meet them. The product design and technical architecture will both evolve as this understanding grows. The aim is to learn early when changing direction is relatively cheap.

A walking skeleton spans an entire capability, so it is built by breaking that thin end-to-end path down into feature slices and delivering them one at a time. Expect it to take a small number of weeks rather than the day or two a single slice takes.

Other names for the same idea

The walking skeleton concept has several names, with slightly different emphases:

  • Walking skeleton, coined by Alistair Cockburn in 1996. The emphasis is on proving that the architecture connects.
  • Tracer bullets, from The Pragmatic Programmer by Andy Hunt and Dave Thomas. Tracer rounds light their own trail, so gunners can watch where the shots land and correct their aim, rather than calculating a perfect firing solution up front and hoping. The emphasis is on feedback on whether we are “hitting the target.”
  • Steel thread, from systems engineering rather than agile. The metaphor is bridge building, where a thread is thrown across the valley first and then used to pull progressively heavier loads across.
  • Iterative, rather than incremental, as described by Jeff Patton with his famous Mona Lisa illustration. See his article Don’t know what I want, but I know how to get it ↗ for the original.

This page uses the term “walking skeleton” throughout for its positive connotations and emphasis on activity and movement.

Not a prototype#

A common misunderstanding is to treat the skeleton as a proof of concept or prototype. A prototype produces disposable code, while walking skeleton code is lean but complete and forms part of the finished system.

Build a walking skeleton when we have some confidence in at least a core backbone of functionality that will meet user needs, and an idea for how to build it. If we don’t even know how to start, use prototypes to answer the questions that stand in our way.

In practice#

To build a walking skeleton:

  • Pick the path, choosing the shortest route through the system that delivers something of value end to end, whether that is a user journey, a data flow, or a transaction. It should still touch the key architectural components: tackling these technology challenges early is important to reduce technical risk.
  • Slice it up into vertical slices so the skeleton is delivered in small increments rather than as one large item.
  • Automate deployment pipelines and tests, alongside writing feature code.
  • Deploy to production, not to a demonstration environment.
  • Hide it behind a feature flag (explained below) or otherwise gate access if it is not yet ready to be made public.
  • Get feedback from real users and stakeholders early and often.
  • Iteratively build on top of the skeleton.

A walking skeleton for a new feature in an existing product can be safely deployed to production in a hidden state using feature flags, long before it is something we would make available to real users. These software switches show or hide functionality and can be used to give selective access to specific people or customers.

Example

A walking skeleton of an e-commerce site may involve:

  • Anonymous access, if integrating with an identity provider is a well-established step in our organisation and we won’t learn much from doing so early.
  • A single-page flat list of the titles of all products, read from a database via an API.
  • An option to choose to buy one unit of a single item, bypassing building a basket initially.
  • Asking the user to enter shipping details for every order, skipping a way to save addresses for now.
  • Integrating with a test instance of a real payment service, if this is an important integration to derisk.

Together these form one thin path from browsing to payment. Each bullet is roughly a vertical slice, and the skeleton is done when the last of them is live. While clearly not ready for real customers, this is enough for friendly customers and prospects to interact with and comment on. Using this will elicit different and more reliable feedback from users than showing them wireframes or mock-ups.

Why it’s worth doing#

The walking skeleton technique significantly reduces the many risks involved in delivering a new product or feature.

  • Early feedback on whether we are building the right thing. Users get to interact with something that works while there is still time and money to act on what they say. A mock-up elicits opinions, while working software uncovers real behaviour, and the two are not always the same.
  • Gives the team a structure to work within. Once the shape of the system is in place, it helps unblock future work and enable team members to work in parallel to build out each area.
  • Something concrete to show stakeholders at every stage. Tangible results demonstrate progress far more convincingly and reliably than a project tracker.
  • Builds customer confidence. Customers who get to see something early in development expect it not to be finished, and they’re glad to see something that genuinely works. A customer who has to wait a long time to see anything working will likely be disappointed that not every detail is as they would have wished. Through early involvement, they become co-creators who can see the priority trade-offs at every step and have a say in them, building buy-in.
  • Early derisking of design decisions and technical complexities. Unexpected challenges are uncovered early when the cost of change is small.
  • Operational from early on. Going live in production forces us to clear hurdles that can easily delay a customer launch if they are left until later.
  • Buys options. Once a simple but working system is live, we can choose to go public with what we have, or keep investing in the more advanced and niche features. As we build upon the walking skeleton we can potentially launch at any point, possibly to a subset of customers, and keep iterating while generating user and business value and with the benefit of feedback from real users. See the cumulative value curves in feature slicing for an illustration of this.

Summary#

  • A walking skeleton is the thinnest end-to-end implementation of a whole capability that can be built, deployed, tested, and used.
  • It is production-quality and it is kept, which is what separates it from a prototype.
  • It forces the build, deploy, and test infrastructure to be implemented early, as part of delivering this thin slice.
  • Choose the slice that touches the riskiest components, not the easiest ones.
  • Feature flags let the walking skeleton reach production without impacting existing users.
  • It is the first iteration of the whole system, not the first increment of one part.

Mistakes to avoid

  • A skeleton that doesn’t walk. Implementing build pipelines, infrastructure, and a health check endpoint gives some technical derisking but none of the user feedback.
  • Routing around the scary integration. The slice should go through the component we are most worried about, not past it, or much of the value of the approach is lost.
  • Letting quality slide. Getting the technical foundations right is essential to building a quality product or feature.
  • Building it but not deploying it. Important risks are deferred if the skeleton doesn’t make its way to production.
  • Not explaining what users can expect. Users need to understand that this is a very simplified early implementation for feedback, not a finished product.