Surfing the Cloud

The Agile Deceit

Brandon Gillespie -

Understanding Feature vs Deliverable Discord

In software development, there is a challenge which, at its root, is about the difference between a feature (described from a user's perspective as something a user needs) and a deliverable (the actual "thing" that is made). If you feel these are the same thing, pay close attention, because not recognizing this difference can leave a trail of bad estimations, meandering work efforts, inability to deliver, technical debt, and frustrated leadership due to your lack of progress and reporting.

Agile processes were built in part to address this challenge, but on some level, Agile can also make it worse. If you have ever felt like your product requests don't respect how much work is required, that your capability to estimate something has a low confidence rating, or simply that your team gets stuck too often in analysis paralysis, it is likely because of not understanding the difference between a feature and a deliverable.

User stories make for an amazing tool that have helped the software development cycle. They simply focus the mind on a request from the customer's perspective. Using phrases like, "as a user I want..." are great aides in this process. But the most common next step is to then assign these user stories as work efforts. This is easy, but it is the problem. Stop it.

Consider a scenario: Product comes to a team of builders and gives them the following user stories:

  1. As a user, I want a flying machine so I can fly about.
  2. As a user, I want this flying machine to have levers to help me go up and down.
  3. As a user, I want a wheel to turn it side to side.
  4. As a user, I want a throttle to increase speed.

With these simplified stories, one can surmise we are building an airplane. The stories are given to the builders, with an expectation that they just begin building. The project manager may even press them for an estimate: how long will this take? The builders begin to sweat, their minds racing while thinking about fuselages and wings — things not part of the specification, but which they know is required.

Fundamentally, the user story describes the feature, or the want, which is very important to understand... but it does not often cover any part of the incidental and secondary things, and this is what causes stress, frustration and discord to the builders. Work must be taken to breakdown the user stories into smaller elements, but it is usually done from the perspective of the features, not the deliverables, and more frustration is had.

What is the common response to address these concerns the builders bring up about things like wings and engines? Create “tech” stories... but they are not stories! In this example, the need for an engine is implied, but not spelled out. It is assumed the builders will just know an engine is needed, but non-builders struggle to comprehend why this is a problem. So when the developer talks about engines, the project manager adds a story "Engine" to the mix… but it doesn’t fit the paradigm of user stories. It is apples and oranges and the builders continue to be stressed because they feel it is still an incomplete picture.

What is commonly missing from this development cycle is the re-orientation of the mind to think about deliverables instead of features — and they are exclusive, not interchangeable. Both have value. Following in our example, we have a few features listed. The common next step is the builders get together and talk about things, in the context of the features, trying to break down what is required into smaller work efforts. But as long as the mind is focused on the feature, it is difficult to truly scope the effort because a user doesn't see or even need to comprehend all of the work required to get their thing done.

Instead, take a moment to reorient the mind onto deliverables. A deliverable is the resulting product required to make the feature happen. Start at the biggest part of the deliverable, and iteratively break it into smaller and smaller elements.

In this case, we recognize that an airplane is required. That is the top:

  1. airplane

Then, we think about what parts are required to make an airplane. There is the fuselage, wings, tail, and engine. This is the second level:

  1. airplane
    1.1 fuselage
    1.2 wings
    1.3 tail
    1.4 engine

Then you recognize you are working in an Agile manner. It isn't necessary to scope out everything up front. In technology, sometimes so much is new R&D work it is hard to know what is required until other elements are completed. Contrast this with building a house, where the fundamental system has changed little over the last few decades. So recognizing that you are developing in an Agile manner, you only need to scope the next work effort, which is chosen to be the wing section.

In pondering how to break it down further, you realize it has at least two more elements: retractable landing gear, and flaps:

  1. airplane
    1.1. fuselage
    1.2. wings
    1.2.1. retractable landing gear
    1.2.2. flaps
    1.3. tail
    1.4. engine

The incredible value of this type of deliverable-focused view is that it helps orient the mind to what must be done (the deliverable), not what is being requested (the feature).

This way, when somebody comes along and is really confused as to why you are working on retractable landing gear when they didn’t ask for that — they asked for controls to make the plane turn left and right — you have a clear plan which outlines why this landing gear is a necessary part of the process (in order to get the plane off the ground in the first place).

Furthermore, this process helps your estimates become much more accurate. By orienting your mind in this manner, you discover things you may not have considered when simply thinking of features. For instance... having a plane is nice, but what if you have no runways or airports? Perhaps part of this process is to ask the user where they plan on taking it, and then building into the deliverable breakdown a few more elements to cover runways and airports.

For many, this process may seem familiar, and I explore the power of using a WBS in an agile world as a DBS, in a separate post.