Skip to content

Deliverables

What are deliverables

Deliverables are a software developer's main output, or "unit-of-work".

While our primary output is lines of code, customers do not care about this (except in so far as the quality of the lines of code affect technical debt).

In a fixed-price contract, the agreed-upon output is a set of features, ie deliverables.

At Dzango, we do exclusively "time and materials" contracts, which in essence means that customers buy our time. But that contract would not last long if we didn't produce tangible results, ie deliverables, in a quantity commensurate with the time purchased.

A broad definition of deliverables

Broadly speaking, a deliverable is a discrete, tangible and assessable output.

It is discrete in that its scope can be explained precisely. A feature either works or it doesn't; a web app works or doesn't work on a specific browser; a bug is fixed or it isn't. "Working on bug X" is not a deliverable. "Fixed bug X" is.

It is tangible in that it can be associated with a physical artefact (within the limits of what "physical" means in a digital environment): If a feature or a bug fix, it can be deployed and viewed on a server; if a report, it is available as a written document, etc.

It is assessable in that the product owner (customer, supervisor, etc.) can verify it: If a feature, it should be working bug-free and according to specs; if a bug fix, the bug-inducing behavior can be replicated and found to be bug-free; if a report (eg ADR), it can be discussed cogently, etc.

Acceptable deliverables

What constitutes a deliverable may vary according to the project. Below is the list that we generally follow.

Features and bug fixes

Features and bug fixes are obviously deliverables in principle, but to qualify they must be:

  • according to the project's Definition of Done
  • available on the designated server (preferably the staging or pre-prod server)

Warning

If it's not on staging, it's not a deliverable.

ADRs

ADRs are acceptable deliverables, provided that they are complete, which means that they must:

  • include a proposed solution
  • include a full analysis of all relevant alternative solutions
  • allow stake holders to make an informed decision

Ticket analysis

A ticket analysis is an acceptable deliverable, provided that it is written in the ticket itself, and is complete, or at least each part is complete, eg testing plan or implementation plan.

Automated tests

Automated tests are an acceptable deliverable, even though they don't quite match the full definition, in that they are not easily assessable by a non-technical stakeholder. However, they provide so much value that they are nevertheless accepted as delvierable, provider that they:

  • all pass during the relevant CI stage (eg on staging server)
  • provide true incremental testing value
  • increase coverage (if coverage is monitored)

Refactorings

Refactorings, by definition, are at constant feature scope, so nothing should be visible to end users, and by extension to stakeholders. So they are not assessable by non-technical stakeholders (except that they can check that no bugs were created, and no feature was changed).

However, refactorings are a necessity of software development, and are therefore accepted as deliverables provided that they are:

  • based on a specific instruction (eg ticket)
  • part of a designated "housekeeping" period devoted almost exclusively to refactorings

MRs/PRs

Merge Requests (Pull Requests in Github) do NOT qualify as deliverables, except in very specific circumstances where:

  • the merging of such MRs and the deployment to staging is not done by Dzango
  • the customer has a CTO who will review all MRs

Deliverable size

The "size" of a deliverable does not matter.

In a sense, the whole app we create for a customer is one big deliverable, but that definition is not practically very useful.

How would we even measure the "size" of a deliverable? In lines of code? That's irrelevant. In number of files changed or modules impacted? That's irrelevant, and possibly dangerous.

The functional scope of the deliverable is a better measure of its size, but too wide a scope makes for deliverables that are difficult more bug-prone and harder to verify. They also tend to always take longer than expected, leading to delays and frustration for all concerned.

Small deliverables, with a limited, well defined scope, are easier to verify and validate. The danger is that in limiting their scope, you lose sight of the bigger picture and come up with a suboptimal design.

To avoid this pitfall, your analysis should be broad in scope, but your outputs (deliverables) small.

It is far better to produce a sequence of small deliverables rather than one big deliverable.

A deliverable's scope should ideally be 1 day, and exceptionnally 2 days. This also makes it easier to respect the Daily Deliverable Rule.

Deliverables vs tickets

A ticket is a deliverable (assuming it is correctly written) but a deliverable is not necessarily a ticket.

As you grow in seniority, more complex tickets will be assigned to you. In most cases, a ticket will take several days, or even weeks, to complete.

Rather than trying to complete this ticket as a unit, best practice dictates that it should be broken up into a series of smaller steps. This makes the ticket easier to resolve and easier to test.

You should take care that each, or most of these steps qualifies as a deliverable, so that you can fulil the Daily Deliverable rule.

This is part of your responsibilities during the ticket analysis. Breaking up the ticket into a collection of deliverables is part of the ticket's implementation plan.