When engaging with a client on a project that will be developed using agile methodologies, what is being promised in the delivery of the project? How do you know if that promise is objectively met?


In a typical client/service-provider interaction, a transaction takes place where the client asks, "can I have a solution that helps me do X?" Then, the provider responds with, "yes, we can build that for you!" The next thing the client says is, "awesome, how much will it cost and when will I have it?" Finally, the provider gives an answer, or a promise, to deliver.

In the traditional waterfall-managed project, as the provider, we can easily see if we've met our promise by comparing our "committed" timeline, budget, and scope to the actual timeline, budget, and scope.

In the agile world, where there is inherent recognition that the plan of what is going to be delivered changes, what are we actually promising when the project starts? Can it be measured?

Waterfall: "I promise to deliver X scope in Y timeline with Z budget." (In the hopes of solving W business need.)

Agile: ?

If I were to take a stab at it, I'd probably say:

"I promise to help solve W business need by iteratively developing and adapting X scope within the confines of Y timeline and Z budget."

The problem with this answer is I'm having trouble understanding how I can objectively measure whether or not this promise is met. How can I reasonably compare committed vs. actual Y timeline and Z budget if I know that X scope will change. How can I measure whether or not X' scope actually solved W business need?

1 Answer 1


What You're Offering

This is a good question, because it highlights a common misunderstanding of agile principles and contracting. In practice, you aren't promising to deliver something with a fixed scope, budget, or timeline. What you're offering to do is to collaborate with the customer in iterative increments, and using framework features to manage scope to fit the budget or schedule on an ongoing basis.

Using Scrum as an example, a typical agile approach is to say something along the lines of:

  1. Each team costs n dollars per Sprint. (You don't have to do this, but I find it adds predictability and averages out for all involved.)
  2. We will collaborate with you to deliver a potentially-shippable increment at the end of each Sprint.
  3. You can adjust the project's priorities at each Sprint boundary.
  4. You can terminate the project at the end of any Sprint where you've achieved enough value or decide that the project won't meet your expectations.

The rest is contractual fine-tuning. The point is that you are working together with the customer to build a product, rather than creating an externality for them. The agile framework that you choose provides some rigor and visibility, but is almost never bounded by fixed scope.

  • Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
    – Mackers
    Commented Aug 28, 2018 at 14:56
  • @Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
    – Todd A. Jacobs
    Commented Aug 28, 2018 at 15:00
  • 100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
    – Mackers
    Commented Aug 28, 2018 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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