Recommended for You:

Getting out
of the box

Success in Tech
Design Thinking


The Agile Deceit

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. It is called a Work Breakdown Structure (WBS). But the WBS has some very important principles, and in my experience few take the time to understand them. WBS's which are task oriented, are a classic example of this lack of understanding.

In an Agile software development world the WBS is also often misunderstood if not simply discarded for being "too waterfall," largely due to a lack of understanding of the distinction between a feature or a deliverable. Or it is simply dismissed because the speaker doesn’t fully understood how a WBS really works. Another problem is in the name itself. Everybody does "work breakdowns" as part of their regular life routine. But a "work breakdown" and a "Work Breakdown Structure" are two distinctly different things, with the latter having a formal set of principles that govern how it works.

To help combat this confusion over what a WBS actually is, I suggest a simple vocabulary change. Instead, call it the Deliverable Breakdown Structure (DBS).

To understand the value, take some time to try a few DBS exercises. Study what makes a good DBS, and remember the key principles:

1. DBS is deliverable oriented.

Plan outcomes (deliverables / products) not actions! Write nouns, not adjectives. I.e.

  1. Wing


  1. Assemble the Wing system

This may feel like it is nit-picking, but it is extremely critical in helping to orient the mind. In the first example, to have a finished wing one must consider all the possible sub elements of the wing, such as landing gear. But in the second example it is easy to assume that the landing gear will just be available, the "task" is now scoped simply to the assembly.

2. 100% Rule

All work to make a deliverable is encompassed underneath that deliverable. If you find a desire to state that to complete one item, another somewhere else in the hierarchy must be finished, then you need to reorganize your hierarchy. This is a very common problem when doing a work breakdown from a feature perspective, and not a formal DBS.

3. Mutually Exclusive

Similar to the 100% rule, this asserts that there should be no duplication across hierarchies. If, to make the wing, one must make a hydraulic system to drive the flaps, but in the tail system you must also create a hydraulic system... the hydraulic system may be better moved upwards in the hierarchy. Otherwise, you might create incompatible systems and duplicate work efforts.

4. Level of Detail

The WBS is commonly considered part of the defined/waterfall project management process because it is such a valuable tool and came into its own decades ago and has become widely used in the defined/waterfall system. But a DBS is merely a tool, not a part of the defined/waterfall system, and the Level of Detail principle clearly defines this.

When analyzing a DBS, the Level of Detail should only be broken down to the level necessary for the work being done in the next work interval, and to verify you have thought about the work effort enough to scope it to your needs. This is a very vague statement, but what it is saying is that you do not need to fully analyze the entire system. Just analyze enough of it to meet your needs, and then you should stop.

In an Agile world, I suggest doing a high level DBS for the overall effort, and then on a regular interval (perhaps monthly) pick different areas and refine them to help you know what to do next.

As counterintuitive as it may feel, I guarantee that a little effort spent adding a DBS into your process will reduce the time you spend in analysis paralysis, it will make your estimates incredibly more accurate, and it will give you a DNA that your project can lean against to keep on pace with where you are trying to go.

The biggest challenge I have found is that most, if not all, of the project management tools in an Agile or software development world have a blind eye to the difference between features and deliverables. Ideally, developers are working against deliverables in the DBS, not features or user stories. The deliverables in a DBS can map to features, but the relationship is more of a two dimensional matrix than a simple direct mapping.

Either way, the first step is to reorient the mind. During this process, stop thinking about features, and start thinking about deliverables. Trying to do the two together simply creates discord and stress through cognitive dissonance as the team wrestles with figuring out how to convert a feature into the actual work scope needing to be done.

Once you have figured out how to keep these two separate, then work on finding a way to use them in parallel with your own tools and processes. If you find something that helps to mesh the two well, please share.

Ideally, in a system such as Jira, one would have a separate object for deliverables, vs stories, and they would be linked. Perhaps three projects: one for stories, one for DBS, one for tasks / flow, with linking between each.