Walking Skeleton: A Simple Prioritization Technique for MVP

The method of prioritization known as the Walking Skeleton emerged in the early 2000s, championed by Dr. Alistair Cockburn, an expert in agile software development who described it as:

… A tiny implementation of a system performing a small end-to-end function, it avoids using the final architecture but ties together the fundamental architectural components. Subsequently, the architecture and functionality can evolve in parallel.

The Walking Skeleton represents the embodiment of your basic architectural concept. It’s not a mere sketch; it’s a genuinely executable and deliverable product that must be accompanied by tests.

Due to the nature of this method, the Walking Skeleton is utilized to prioritize features in an MVP, determining which ones are absolutely critical for the product to function. Sometimes, the Walking Skeleton may be smaller than a full MVP, but it prioritizes essential features.

How does it work?

All features are laid out in the form of columns, acting as vertebrae, and stories hang down like ribs. This representation visualizes the importance of user stories within specific features and focuses on implementing one set of stories at a time.

Once you’ve established the foundation and listed all your core features, you can start prioritizing stories in each rib. The higher the priority of a story, the closer it is to the backbone, making it more crucial and relevant. Stories towards the end are less important.

After placing the stories, you’ll see the minimal implementation of your product at the top of the “Story Map.” This is what Dr. Alistair Cockburn refers to as the “Walking Skeleton”: a very minimalistic but functional product, typically ready for user testing.

When to use it?

The primary goal of the Walking Skeleton model is to ensure that the MVP eventually “walks,” meaning it works according to requirements. Therefore, when evaluating features using this model, you’ll need to determine the following:

1. Everything necessary for the system to function.
2. Features that must be there according to requirements.
3. Features aligning with business goals and values.
4. Features that have passed testing.

By choosing and implementing these features, you’ll end up with a functional MVP. However, this model doesn’t imply delivering a more robust and complex product with numerous additional features or additional business value. You’ll have the bare functionality at your disposal.