1

How can I determine a project end date when Product Backlog Items (PBIs) are not estimated? Consider the following two examples:

  1. I am on a project that is at the beginning. I'm asked when the project will end, but I do not have a product backlog that has estimates for the PBI's, especially epics and stories too big to size. How do I approach this so that I can provide the stakeholders an end date?
  2. 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. Is this normal behavior and how do I approach this situation?
  • This appears to be two separate questions. I tried to consolidate it, but you may need to split your questions up into separate posts. – Todd A. Jacobs Jun 3 '14 at 19:28
2

Create a goal oriented roadmap

It appears that you are following an agile development process. However, your (or your stakeholders?) expectation seems to be more waterfallish - fixed scope (list of features) and fixed time (committed delivery date) without even putting in the effort to do a detailed estimation! This is a recipe for disaster! No wonder you are seeing "the end date being pushed back and back and back".

I would recommend a different approach. Your Product Owner should set up a series of meetings with the stakeholders:

  1. I expect that you already have your Product Vision documented. If not, you can use something like Roman Pichler's The Vision Board as a template to create one.

  2. Create a goal oriented roadmap along the lines suggested by the same author in Working with an Agile Product Roadmap. "The benefit of a goal-oriented roadmap is that it shifts the conversation from arguing over features to agreeing on shared goals."

The timeline for the goal oriented roadmap is still a judgement call for the dev team. However, the difference here is that nothing will be scheduled into the sprints that is not absolutely essential to achieving the goals. And the dev team is empowered to come up with better and more productive ways to achieve the goals.

1

TL;DR

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:

  1. Differentiate between scheduling estimates and targets.
  2. Continuously revise your project plan based on evolving constraints such as scope or time.

Projecting Schedules

There are fundamentally two ways to determine a project's end date:

  1. By Scope

    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.

  2. By Fiat

    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:

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:

  1. Re-prioritizing the Product Backlog each Sprint to maximize value.
  2. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.