We are starting our new project in Scrum/agile method. The client asked us to provide the estimations on their high level requirements. We will be able to form the team during Sprint 0 which we will form in few weeks from now. I understand that the team will provide estimations (T shirt size/story points) based on that we will arrive at the end date. But in the context we are working now, the team will be added later. So, i have broadly three questions

  1. How will I come up with the dates based on scope without having the team now? (I dont have historic data also)
  2. How do I determine scientifically the number of resources needed to finish the release ?
  3. How different are the estimates and estimation for an Agile project done vs Waterfall?

You have to estimate all three variables together. Estimating one without the other or other two results in an estimate of planning value that is not credible at all. The formula is Duration (days) = Work (hours) / Resource utilization (FTE). However, this is very deterministic and actual results do not really follow this. It is good tool to get grounded, but you need to treat all three variables as variables that are both dependent and independent of each other.

If you do not have historical data or reliable heuristics, you are limited to "engineering" type estimates using your SMEs and several different techniques. The limits to this are caused by human biases, politics, and agendas (like pricing to win), so this is a rather unreliable of planning your work. However, if this is all you have, then this is all you have; measure your risks accordingly and build in reserves where you can.

I do not think there are a lot of estimate differences between agile and traditional methods but I'll leave that to the agile experts.

  • "if this is all you have, then this is all you have; measure your risks accordingly and build in reserves where you can". Nailed it! – Tiago Cardoso Mar 19 '14 at 0:17

I believe the important thing is the presence of the 'client'. The team psychology differs whether the project is internal or external. I work for a software vendor. The approach that we follow is, make estimations using waterfall approach but execute it using agile. However, you need to be careful with your estimates as agile measures the velocity in terms of story points where as your waterfall estimates are based on hours. We have not yet mastered it but for sure it is slippery slope. Another method is to provide rough order of magnitude estimates but price it on per sprint basis. There are other threads in this forum that explain these methods well.



Agile is based on the knowledge that scope is variable, therefore effort estimates are unreliable and not supported.

Agile projects are delivered at regular intervals or continuously. There is no "deadline" as such, and since one can't do estimates without the team -- one can't do estimates without the team in waterfall either -- estimates are made as late as possible in the game, when more domain knowledge usually results in better numbers.

In an agile project you need to agree with your customer that each iteration will cost X and that you guarantee:

  • a certain minimum number of iterations
  • a release each iteration

The customer will guide the project and decide during development what features are going to be delivered. The total cost of the project will be depending on how many iterations the customer will decide to pay for. Each will deliver a set of features.

In other words, the estimation is done each iteration. The software will be (potentially) delivered in any case each iteration so you can think of each as a "fixed time" mini-project.

This may sound like a step back from waterfall, but it is a very powerful approach which has very desirable qualities:

  • estimation is only made when something is about to be developed (not at the beginning)
  • there's optimal support for scope change and value maximization of the output (value is continuously delivered, not once per project)
  • there's support for changing value of features (if the next planned feature is not valuable, it won't be developed)
  • estimates impede negotiation: there are many ways to produce a feature. The exact details are negotiated until the last minute in order to allow for maximum value and efficiency (versus "following the plan" in waterfall)

If your customer values using an agile methodology -- not all customers and projects can accept it -- then I would think they expect something like the above and not a classical estimate.



To accurately estimate a project's time, scope, or resource requirements, you need to perform some analysis and estimation; this is true regardless of your chosen framework. One can generally accomplish this as a mini-project where an estimate for the "real" project is its primary deliverable.

Your other sub-questions will depend a great deal on your chosen project management framework. Waterfall is a model, while "agile" is a set of frameworks based on the Agile Manifesto. Some useful comparisons can be made, but specific practices can vary quite widely.

Below are some specific suggestions for how to accomplish your objectives, regardless of what framework you choose. The suggestions also attempt to highlight some of the differences between traditional and agile methodologies so that you can consider what might work best for your specific situation.

Timebox Your Delivery

How will I come up with the dates based on scope without having the team now?

You don't make these kind of estimates based on scope, because you have no way to estimate the level of effort or time required to meet that scope. Instead, if you want to be agile, you define a time box for each iteration and each milestone.

For example, if it's now March 1st, your client might define September 1st as their target delivery date for the project. Your team then has a time box of six months to deliver as much scope as possible within that predefined time box.

In addition, you will define iterations as additional time boxes within which you will commit to delivering a set of potentially-shippable features. For example, a six-month project will give you approximately 12 two-week iterations. In each iteration, the client will define what features they want to prioritize for that single iteration, and the team will commit to the scope of work they are confident that they can complete within that two-week time frame.

The time box and the goal for each iteration is fixed, but the scope of work that can be successfully delivered over the lifetime of the project is variable.

Kick Off a Project-Planning Project

How do I determine scientifically the number of resources needed to finish the release?

You can't. Oh, there are frameworks that pretend that they can, but unless your project is a manufacturing project with well-defined tolerances no initial guesstimate survives the real-world project process without changes in scope, time, or allocated resources.

In an agile project, the number of human resources is generally fixed (e.g. a fixed team size and/or a fixed number of teams), but the scope and the number of iterations will vary based on the needs of the project. This is generally what you need, but there are alternatives.

To provide a reasonable estimate of how much a project will cost or how many iterations it is likely to take, you must actually create a project spike to create those estimates. In other words, you might form a short project to go over the feature list (a.k.a. Project Backlog), define and estimate stories, and maybe even perform a short story spike or two. This sort of calibration project is actually quite common, and many larger clients are willing to invest in a "project-planning project" in order to gain more accurate estimates.

Waterfall and Agile Frameworks Have Different Value Models

How different are the estimates and estimation for an Agile project done vs. Waterfall?

Waterfall, even modified waterfall models, are basically designed around up-front planning and then trying to control for deviation from this initial plan. Because the Cone of Uncertainty is typically largest at the start of a project, up-front planning is generally not successful in controlling complex or complicated projects.

Agile methodologies, on the other hand, generally use just-in-time estimates at a granular level, thereby reducing the Cone of Uncertainty to more manageable levels. Frameworks like Scrum also provide for just-in-time analysis and design, which help to maximize the accuracy of short-term planning.

Another way to look at it is to say that both types of methodologies are bad at long-term estimation and planning, but agile frameworks acknowledge that and take a value-driven approach to delivering features frequently in a tight feedback loop in order to maximize value for the project stakeholders.

In short, if your project can deliver incremental value, then agile frameworks are a viable option. If your project truly can't deliver any value unless all predefined tasks are 100% complete, then frameworks that require up-front analysis and design and a less emergent production cycle may be necessary. Your mileage will certainly vary.

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.