Project Deadlines in an Early State (Scrum Project)

Question

How to deal with early projects states where serious deadline agreements cannot be made yet?

1. We are in an early stage of the project with new people.

2. The team is small and everything is new (technology and people): In short. A lot of dynamic factors.

3. We are still in the phase were we find out how much we can do in a single sprint

4. A lot of important things are not yet defined in the Backlog (just exist as some vague marketing statements)

At the same time some Stakeholders already want to set deadlines or milestones.

But I would need these two things to seriously agree on something:

1. Having some more experience in how fast the team performs
2. Backlog with every feature that the Stakeholder wants to define the date or deadline for.
3. Seriously agree on something would mean for me that between expectation and reality are not factors like two times longer or higher.

My question is how such situations can be handled or should be communicated to Stakeholders (from a Product Owner perspective).

Update Regarding Comment of Jeff: It is very interesting to have these two kinds of aspects: Date-driven and scope-driven. I guess a combination would be best. I mean a date-driven goal would mean, that you make the release at the given date no matter what happens, right? (We are still in the learning process of Scrum methodologies. So I guess hints in the direction of Roadmaps and Scrum help us in general.)

Answer 1

Use this opportunity to firm up the vague marketing statements

If the stakeholders are interested in firming up the schedule, it is a good thing. Use this opportunity to create the first draft of the Goal Oriented roadmap in consultation with the stakeholders. This will cover the following:

1. How often you plan to release and what will be the main goal of each release. The example in the link shows quarterly releases. But, you can do monthly releases, for example.

2. Once you have identified the goals, list the high-level features necessary to reach the goals.

3. Next define the metrics, the measurements or key performance indicators (KPIs) that help determine if the goal has been met, and if the release was successful.

By preparing the above roadmap with heavy involvement from the stakeholders you get their buy-in.

Set the expectation with the stakeholders that you will work with the development team to firm up the first release and the next two will be subject to a 25% revision. Releases beyond the third one are tentative. Explain to them that the team and technology are new.

Work with the development team to estimate the high-level features by breaking some of them into granular stories and estimating those in detail. The metrics/KPIs that you wrote in the roadmap should help you write better acceptance criteria for the stories.