Daily Deliverable Rule
The Daily Deliverable Rule (DDR)
Produce 1 deliverable every single day. Size does not matter.
What the rule does not say
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.
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.
Large, complex tickets
The more senior you are, the more complex the tickets assigned to you. In most cases, a ticket will take several days, or even weeks, to complete. The rule does not expect you to complete such complex tickets in 1 day.
However, it does expect you to work out, as part of your ticket analysis, a roadmap to completing this ticket, which would include at least 1 deliverable per day.
What is a deliverable
Features and bug fixes
Features and bug fixes are obvious deliverables — provided they are made available on the
staging server, where the product owner can verify them.
If it's not on staging, it's not a deliverable.
On some days, there may be no opportunity to create a feature or bug fix. If this happens, the definition may be extended to include anything that has an output that is verifiable by the product owner.
- Documentation (in ADR format)
- Ticket analysis
Automated tests are considered as deliverables.
We expect every developer to report on the day's deliverable(s) in slack or whatever chat platform is use for the project.