Separate budget for maintenance?
Dear Scrum.org community!
We'll release an application for a client soon. It's the first release, 3 months of development. The backlog is enough for about 1 extra month of development after the release. After that, there is "nothing to be built".
What would you suggest:
A) asking the customer to have 2 separate budgets: one for developing new features and another only for maintenance
B) Having only one budget and deal with the innovation X maintenance issue on the Sprint Backlog level, having the PO deciding how much one or the other should be included in the Sprint.
C) Pushing the client to elaborate on the possible scope for more than 2-3 months of development
I really appreciate any help you can provide.
Why have 3 months gone by without releasing any value, when the maximum length of a Sprint is one month?
To me this sounds like a problem that your organization needs to answer because it has nothing to do with Scrum. You have already made the decision to delay delivery of value when Scrum recommends continuous, incremental delivery so you abandoned Scrum 3 months ago. This decision is closer to a Sales decision more than anything else.
I will offer this advice though. What has history shown about the need for maintenance on the work your organization delivers? Using empiricism, you can make a decision based upon the past, propose that to the client with transparency on how you determined it and let them decide if that is acceptable or not.
Thanks for your reply, Ian.
The client was skeptical about releasing the app with 1-month scope, claiming that it would not be possible to deliver value only with that scope.
Have you dealt with clients who are skeptical about it? Any tips on arguments I can use?
Daniel, you are right; we abandoned Scrum 3 months ago if we look at it by the book. Could you elaborate please on what do you mean by 'is close to a Sales decision'...?
The client was skeptical about releasing the app with 1-month scope, claiming that it would not be possible to deliver value only with that scope.
Have you dealt with clients who are skeptical about it? Any tips on arguments I can use?
Each Sprint is a learning experiment where value may be found in the lessons that are learned and the uncertainty that is reduced.
Is the client right that no such value can be obtained here? If so, and there is no need for empiricism, the outcomes that are to be had from Scrum are unlikely to materialize.
This decision is closer to a Sales decision more than anything else.
To me it sounds more like something your Sales organization should have negotiated when the contract was drawn up and signed. Your question is about how to have the customer pay for the work that needs to be done for a product that you are creating for them. What was the expectation set with the customer about the work that would be done after you delivered the working product? That is typically something it the contract. This doesn't sound like a Scrum problem at all to me. The Scrum framework is about the work related to creating and maintaining a product. How it is paid for is not a concern for the framework.