1

Scrum is very good when you manage a T&M project. But what about projects where you are paid for features or tasks done? Is Scrum applicable to projects with outcome-based pricing?

  • That's a really good question when talking about contracts. I'd suggest, if that's what you want to know, to consider a separated question on how the PM can manage the contract aspects for such project types. – Tiago Cardoso May 4 at 16:21
  • Good question. pm.stackexchange.com/questions/29636/… – Daniel May 4 at 18:14
3

"Outcomes" Aren't Synonymous with Fully-Fixed Constraints

In Scrum, the burn rate of each iteration is (relatively) fixed. The flexible sliders are scope and schedule. So, "outcome-based pricing" is certainly possible so long as you can adjust scope and schedule, but it isn't feasible if you're abusing the term to mean "fixed price for fixed scope."

If the desired outcome is "build a new web site," then the contract could specify a Definition of Done that includes the site's expected feature set. In turn, the vendor would need to estimate the number of fixed-price iterations needed to get to the desired scope, and then track against that.

So, what happens if work takes longer than expected, the scope changes, or the work suddenly becomes schedule-driven? With Scrum, you'd need to collaborate with the customer to trim scope, adjust the number of iterations, or modify the budget to meet the changing targets.

In other words, Scrum requires active and ongoing customer collaboration. The customer has an opportunity every single Sprint to:

  1. Inspect the increment of work for the Sprint.
  2. Identify refinements or new work related to the product.
  3. Decide to "fail early" and scrap the project if it doesn't look like time, budget, or quality objectives can be met within acceptable tolerances.

However, trying to replicate waterfall-style, upfront planning with fixed scope, fixed schedule, and fixed price is not agile, and is not a good fit for Scrum. Contracting for a well-defined outcome using Scrum is possible, but beware any attempt to lock all three elements of the Iron Triangle at the same time. That doesn't work with any framework, and can't work with Scrum.

| improve this answer | |
1

Scrum should be focused on delivering outcomes, so yes, it is applicable. I think it would be very important to have a common understanding of what "Done" is so that you aren't charging for something the client can't use and they aren't constantly moving the goal posts. Past that, it should be a perfect fit.

| improve this answer | |
0

Yes Scrum is applicable. A product backlog is absolutely supposed to be about outcomes rather than tasks. Scrum won't help you solve the problem of how to price those things fairly but Scrum does support the kind of accountability and transparency that helps make a successful commercial piece of work.

| improve this answer | |

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.