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?
2
-
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, 2020 at 16:21
-
Good question. pm.stackexchange.com/questions/29636/…– DanielMay 4, 2020 at 18:14
Add a comment
|
3 Answers
"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:
- Inspect the increment of work for the Sprint.
- Identify refinements or new work related to the product.
- 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.
answered May 1, 2020 at 17:22
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.
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.
