<p>A "Walking Skeleton" is a form of "proof of concept" of your basic architectural concept. Where a proof of concept typically focuses more on a single functionality, a "Walking Skeleton" is a minimalistic end-to-end implementation. A "Walking Skeleton" is not an outline of your concept (only a "skeleton") but is really executable and shippable (it can "walk" :O) and should be accompanied with tests.</p>

<p>Alistair Cockburn <a href="http://alistair.cockburn.us/Walking+skeleton" rel="noreferrer">has described it</a> (and is being quoted often):  </p>

<blockquote>
  <p>A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.</p>
</blockquote>

<p>The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in <strong>working, shippable and testable code</strong>. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.</p>

CC BY-SA 3.0
2017-03-29T12:59:49.520Z
Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A *skeleton* of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.
Dan Cornilescu
CC BY-SA 3.0
2017-03-29T13:01:34.750Z
I like the "meat" term, fits really well with the terminology used :P
7ochem
CC BY-SA 3.0
2017-03-29T15:39:02.237Z
Great answer. I guess it's the delivery pipeline equivalent of a minimum viable product.
Adrian
CC BY-SA 3.0
2017-03-29T16:55:50.270Z
This does sound similar to minimum viable product, but at a more granular level- "minimum viable component" perhaps.  Returning 200 from a service just to get it "running" sounds like a stub to me.
Dave Swersky
CC BY-SA 3.0
2017-03-29T12:48:56.553Z
2017-03-29T12:48:56.553Z
7ochem
<p>One of my agile teams has taken an interesting approach in the early stages of their project.  Instead of starting the project with a Sprint 0 where they setup code infrastructure and decide on the solution architecture, they have started building a "Walking Skeleton", which they describe as a DevOps practice.</p>

<p>What this seems to come down to is building something very small (in the case of an API a single endpoint that just returns <code>200-OK</code>), getting this working in continuous integration, and building out the continuous delivery pipeline to deploy this through each of the environments:</p>

<blockquote>
  <p>Development ► Test ► UAT ► Pre-production ► Production</p>
</blockquote>

<p>In the process they have managed to tick off many of the non-functional requirements that could have been missed if deployments were left to the last minute.</p>

<p>My question is this: what is a "Walking Skeleton" and what benefit does it provide to a Agile team following DevOps practices?</p>

CC BY-SA 3.0
2017-03-29T11:13:34.877Z
Love this one, I can share an actual (last week) thing and what was the outcomes from this after lunch
Tensibai
CC BY-SA 4.0
2019-12-30T14:56:57.763Z
so often I am puzzled as learning new things in DevOps, it's like "wait... this is so much common sense! and yes more effort put into sustainability."
Ta Mu
<terminology><culture><practices><patterns>
What is a "Walking Skeleton"?
Richard Slater
# What is a "Walking Skeleton"?

(Asked by: username_0 on 2017-03-29)

One of my agile teams has taken an interesting approach in the early stages of their project. Instead of starting the project with a Sprint 0 where they setup code infrastructure and decide on the solution architecture, they have started building a "Walking Skeleton", which they describe as a DevOps practice.

What this seems to come down to is building something very small (in the case of an API a single endpoint that just returns `200-OK`), getting this working in continuous integration, and building out the continuous delivery pipeline to deploy this through each of the environments:

> Development ► Test ► UAT ► Pre-production ► Production

In the process they have managed to tick off many of the non-functional requirements that could have been missed if deployments were left to the last minute.

My question is this: what is a "Walking Skeleton" and what benefit does it provide to a Agile team following DevOps practices?

**Tags:** terminology, culture, practices, patterns

> **Comments:**
> **username_1**: Love this one, I can share an actual (last week) thing and what was the outcomes from this after lunch  
> **username_2**: so often I am puzzled as learning new things in DevOps, it's like "wait... this is so much common sense! and yes more effort put into sustainability."  

---

## 1 answers

### Answer by username_3 on 2017-03-29. Score: 52 | Accepted answer

A "Walking Skeleton" is a form of "proof of concept" of your basic architectural concept. Where a proof of concept typically focuses more on a single functionality, a "Walking Skeleton" is a minimalistic end-to-end implementation. A "Walking Skeleton" is not an outline of your concept (only a "skeleton") but is really executable and shippable (it can "walk" :O) and should be accompanied with tests.

Alistair Cockburn [has described it](http://alistair.cockburn.us/Walking+skeleton) (and is being quoted often):

> A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in **working, shippable and testable code**. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.

> **Comments:**
> **username_4**: Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A *skeleton* of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.  
> **username_3**: I like the "meat" term, fits really well with the terminology used :P  
> **username_5**: Great answer. I guess it's the delivery pipeline equivalent of a minimum viable product.  
> **username_6**: This does sound similar to minimum viable product, but at a more granular level- "minimum viable component" perhaps.  Returning 200 from a service just to get it "running" sounds like a stub to me.  

---

