The document discusses why deadlines should never be communicated to development teams in Scrum, as it can lead to lower quality work. It outlines two scenarios: 1) fixed deadline and scope leads teams to cut corners; and 2) variable scope to meet a fixed deadline allows for continuous forecasting and adjusting scope. The key points are that communicating deadlines provides no benefits and can incentivize lowering quality; variable scope and forecasting based on team capacity better supports high quality work. Setting deadlines goes against agile principles and the Scrum framework.

1. COMMUNICATED DEADLINES = BAD QUALITY
Why deadlines should never be
communicated to the Development Team

2. Introduction – This presentation
• This presentation outlines my views on why deadlines
should never* be imposed on the Development Team and
why doing so would lead to bad quality
• This is based on my experiences in my context, and may
or may not be applicable to you
*if you value quality higher than releasing on a certain date

3. Preface
• In this presentation I am referring mostly to a single scrum
team working on a product
• You can of course assign multiple Scrum Teams to a
product to produce more in a specific time period – but
remember that people are not resources that can be
shuffled between teams to ramp up and down
• This is what would be the “Cost” variable in the Project
Management Triangle [2]
• Adding multiple teams to products introduce other
problems which I will not discuss in this presentation

4. Definition of Quality
“Quality is value to some person.”
Gerald Weinberg

5. Deadlines
• There is something inherently flawed with the idea of deadlines
for complex projects
• When something is complex, that means it is unpredictable
• When you cannot predict something how can you plan around
it?
• You need to gather more information to disperse the complexity
• Inspect and Adapt – The Scrum Mantra

6. Scrum Framework [1]

7. Definition of Done [1]
• In Scrum you set the expected level of quality in the
Definition of Done for the Development Team
• Definition of Done is set by the Scrum Team – The
Product Owner, The Scrum Master, and the Development
Team
• The Definition of Done is a contract between the Scrum
Team and it’s stakeholders which defines the expected
level of quality

8. Provocative Statement
“Communicating a deadline to the Development Team will
at best do nothing, and at worst result in bad quality”

9. The Three Variables
Scope TimeQuality

10. The Two Scenarios
Scenario 1
Scenario 2
Time Scope Quality
Fixed
Fixed Fixed
Fixed
Variable
Variable

11. Scenario 1
• In this scenario there is a fixed deadline, and the scope is
not negotiable
• In reality this means that the Development Team has to do
whatever it takes to finish the scope before a specific date
• This means that they have to cut corners and allow
technical debt to build up, unless the deadline is set so far
in the future that it is basically irrelevant
• In this case it is fine to communicate the deadline, and it
means that we do not see a great value in high quality

12. Scenario 2
• This is hopefully the more relevant scenario
• We have a deadline, and we have an expected quality
level that we are not willing to compromise on
• In this case we should allow the Development Team to
start working with the product or feature, and ask for
continuous forecasts on when the Development Team
estimates to be finished with all the stories in their backlog
• If the forecasts do not meet our fixed deadline, then we
remove stories from the backlog until the deadline is met

13. Do not communicate the deadline!
• Communicating the actual deadline in scenario 2 adds no
value!
• The Development Team will work in a sustainable pace
with or without a deadline
• The Development Team will work according to the
priority in the backlog with or without a deadline
• Knowing that there is a deadline will at best do nothing,
and at worst incite the developers to cut corners with
regards to quality

14. Forecast Accuracy
• The Development Team can continuously give forecasts
to the Product Owner about when they think they will
finish the stories in the backlog
• The forecasts will be less reliable at the beginning of the
development process, and more reliable the longer the
Development Team has worked with the product or
feature
• When the Development Team starts their work, the initial
forecasts will be very inaccurate, and the Product Owner
will need to wait a few sprints to get a more accurate
forecast

15. Minimum Scope
• What if we reduce our scope continuously to meet the
deadline, but end up in a state were we reach the
minimum viable scope, and still cannot meet the
deadline?
• Either push the deadline, or accept lower quality – but
be open and transparent about the decision
• Don’t expect the Development Team to magically work
faster with the same quality of work

16. Team Motivation
• Deadlines in themselves do not motivate anyone!
• Motivation is much more complex than the whip and the
carrot
• Do not use motivation as an argument for imposing
deadlines on a Development Team

17. But I want Deadlines!
• If you intend to set and communicate deadlines even
though it is bad for quality, be open and transparent about
why you set the deadline
• “We need to meet this deadline because of X, and if you
need to cut corners to make it, then do that.”
• Don’t hide that you accept lower quality to get the product
out on a specific time

18. Remember …
• When you set a fixed deadline you are plan-driven instead
of value-driven
• If you are plan-driven, then you are not adopting Agile
values, and you are not working according to the Scrum
Framework
• Plan-driven = Waterfall

19. Conclusion
• In Scenario 1 we say directly that we do not value quality
higher than the deadline
• In Scenario 2 if we communicate a deadline to the
Development Team we are at best adding no value, and at
worst giving silent approval to cut corners to meet the deadline
• When you communicate a deadline, you are telling developers
to do what it takes to meet that deadline
• Deadlines in themselves do not motivate anyone
• Be open and transparent if you set deadlines
• Setting fixed deadlines is not Agile and not Scrum

20. References
[1] The Scrum Guide
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
[2] The Project Management Triangle
https://en.wikipedia.org/wiki/Project_management_triangle