Does Scrum have a Delivery Date?

Yes it does, but it will be a “Forecast”.

When working in complex environments such as software or product development, factors arise that will affect our progress. Most of the time, it is not possible for us to know and control these factors in advance. That’s why we create estimates instead of creating a perfect plan. And these estimates are likely to change as time passes and work is done.

As a matter of fact, the delivery date cannot be exact in traditional project management as well. Because unpredictable and uncontrollable factors also play a role here. That’s why it’s healthier to turn things into an adaptable plan that we know will change, rather than squeezing things out to get things done quickly and by the promised date.

So, how do we say “This is not possible” to stakeholders who expect precise delivery dates from us, and moreover, who are waiting for us to get the job done till the delivery date they provided? How do we come to terms with them?

1. If the delivery date is the most important, we can review the scope with stakeholders and find the answers of two questions: What can we set aside? What are non-mandatory requests?

2. If scope or a set of features are the most important things, we can re-discuss timing. Is it a high quality product wanted or not?

To do these:

1. We should have data (ideally for a few months) about our historical speed and capacity.

2. We should have a general idea of what we want to do. Not too much, but enough detail.

3. We must have time to plan and anticipate (Like 1 hour for 1 month of work).

Once these conditions are met, we can create realistic estimates based on the data.

We must admit from the outset that these forecasts are not exact and our plan will change.

We must create as much visibility as possible about any change in our plan and share it with everyone involved in the product development process.