Skip to content

Daily Deliverable Rule

The rule

The Daily Deliverable Rule (DDR)

Produce 1 deliverable every single day. Size does not matter.

What the rule does not say

Size

The rule does not specify a minimum size or scope for the daily deliverable. It only specifies a minimum quantity of 1.

As developers, we cannot be at peak productivity every single day. There will be bad days, where we won't do much. The rule recognizes this.

Nevertheless, the rule does require at least 1 deliverable, even if it's a small one, during such days.

Other constraints

The rule says nothing about other deadlines (sprints, milestones). These still remain to be followed. Of course, the DDR is compatible with such other constraints.

So while you will not get into trouble for producing a small deliverable one day, you will get asked questions if you produce small deliverables for several days running.

Large, complex tickets

The rule does not expect you to complete complex tickets in 1 day.

However, it does expect you to work out, as part of your ticket analysis, a roadmap to completing a complex ticket. which would include at least 1 deliverable per day. This should be part of your analysis' implementation plan.

See Deliverable size.

The 2-to-2 pattern

The appropriate time period to produce your deliverable should not be the calendar day, ie 9 to 6.

Instead, you should decide on your deliverable at 2pm on day 1, and produce it at the latest at 2pm the next day. In other words, the time period is 2pm one day to 2pm the next day , or 2-to-2 for short.

There are many benefits to this approach, both for yourself and others:

  • If you are delayed, say by 2 hours, then instead of having to stay after 6pm until 8pm, you simply finish your deliverable at 4pm instead of 2pm. This means less inconvenience and less stress for you. Your team leader is less inconvenienced because they can still review your deliverable and deploy it to staging during their working hours.
  • By starting work on a deliverable one day, and finishing it the next day, your brain will unconsciously process the issues during the night. You may very well wake up the next morning having figured out a better solution, or identified an issue you had missed the day before, etc.
  • Depending on the customer's time zone, you may also provide them with the opportunity to review your deliverables earlier during their day, so less inconvenience and stress for them, and a higher likelihood that your deliverables will get reviewed that day.

What is a deliverable

For details, please see the list of acceptable deliverables

Here is as summary of what constitues acceptable deliverables:

  • Features
  • Bug fixes
  • ADRs
  • Ticket analysis
  • Automated tests
  • Refactorings

Daily reporting

You should report your daily deliverable(s) as part of the Daily Synchro.