How can I determine a project end date when Product Backlog Items (PBIs) are not estimated?
The short answer is, You can't. If your project schedule isn't based on empirical evaluation, then it's arbitrary. If it's arbitrary, then you might as well throw darts at a calendar to pick your milestone dates.
To have a meaningful end date for your project, you need to:
- Differentiate between scheduling estimates and targets.
- Continuously revise your project plan based on evolving constraints such as scope or time.
There are fundamentally two ways to determine a project's end date:
Work packages, project management overhead, and fudge factors (e.g. slack or padding) are estimated in calendar time to define an end date based on the scope of the deliverables.
The project's delivery dates are fixed targets defined by management. The project then adjusts scope as necessary to deliver as much value as possible within the management-defined time box.
Picking the Right Scheduling Method
Which method you choose depends on the project constraints you are best able to adjust within your project. As an illustration, consider the Project Management Triangle:
As a matter of empirical experience, one can generally choose between feature-completeness or inflexible delivery dates. One generally can't have both without sacrificing quality or expanding the budget. In addition, if you jettison quality or bust your budget, your project is more likely to fail (given any reasonable definition of "failure").
Estimation Errors Require Adjustments to Scope or Schedule
I have a prioritized backlog and I provide the stakeholders with an end date but we discover new information or PBIs that were estimated at 5 story points but are actually 8s, resulting in the end date being pushed back and back and back.
This is "normal behavior" (not desirable, but normal) for projects that have poor estimation techniques and have not clearly differentiated between schedule estimates and schedule targets.
Your "end date" must either be an estimate based on reasonable decomposition of your work packages, or a fixed management target. Since you didn't determine your end date by scope, your projected end date was determined by fiat. Therefore, you must continually adjust scope (e.g. the features or value that the project will deliver) until it fits within the agreed-upon time box.
In Scrum, this is handled during Backlog Refinement and Sprint Planning by:
- Re-prioritizing the Product Backlog each Sprint to maximize value.
- Limiting the stories accepted into each Sprint based on current team capacity.
Regardless of whether you use an agile methodology or not, the point is that failure to estimate (or a continuing pattern of poor estimation) requires that you routinely adjust your project plan. This may mean routinely adding or removing features from the project's scope to fit the remaining time available, or continuously adjusting the projected delivery date based on the project's current progress.
All projects have variance from planned values. How one deals with the variance depends on the current business objectives and the project management framework in use.