Agile / Scrum scope includes new work with schedule extension but no additional cost?
Hi everyone,
We got a scenario where we are having differing view with a client.
In our proposal to the client, there are 2 main releases. It is stated that the first is to be in QA environment and the second will be in production environment. As you are aware, releasing to production will include additional activities such as penetration test, data migration / syncing, support etc. The contract has since been signed.
Our client now wants release 1 and 2 to be production releases. While they are willing to extend the schedule to cater, they do not think they should be charged for the addition work as they view it should be catered as this is an Agile-approach delivery. The client is also not willing to swap out current scope to cater for this additional work.
While we do not intend to charge the client for any reusable or existing work, we do intend to charge them for work that would otherwise not be done per proposal. Eg, we do not intend to charge for data migration documentation nor scripting (reusable for release 2), but we do intend to charge addition for the actual execution of data migration for release 1. These are also additional cost on our end.
Can anyone advise if scope increment (not replacement) by extension of schedule without additional cost is within Agile / Scrum delivery approach?
Thanks in advance!
they do not think they should be charged for the addition work as they view it should be catered as this is an Agile-approach delivery.
If you've agreed an agile approach with the client, why are you even considering a so-called "release" of work (release 1) which will fail to meet a Definition of Done of release quality?
Is penetration test, data migration / syncing, support in the contract?
- penetration test should be done each incremental per scrum for definition of done.
- data migration is one time? The script and documentation can/should be included as task in sprint. Execution depend if you required to run each release, definition of done.
- Support? Fixing bug or answering user question?
I think we need to be clear about Scrum/Agile-approach delivery vs contract issue.
The original intention for release 1 is to "release" work to QA environment, this was in the original contract. So that's the definition of done from our perspective. Now with the additional work (execution of VAPT, Data migration etc) for release 1, we have differing views in terms of whether this addition work is chargeable since it was not in contract.
In your opinion, is this additional work chargeable?
In our proposal to the client, there are 2 main releases. It is stated that the first is to be in QA environment and the second will be in production environment.
While they are willing to extend the schedule to cater, they do not think they should be charged for the addition work as they view it should be catered as this is an Agile-approach delivery. The client is also not willing to swap out current scope to cater for this additional work.
we do intend to charge them for work that would otherwise not be done per proposal
All of these statements indicate to me that you aren't using the Scrum framework and you aren't necessarily being agile. It reads to me that you are doing a contractual based development engagement because there is no iteration or adaption based on changing needs or new information. You have taken on a fixed price, fixed scope, fixed time project and the customers have agreed to the same thing. Now the customer wants a change so you should be negotiating with them on the revisions to the contract. There is nothing agile or Scrum involved in this.
You may use agile or Scrum terms, you may use some of the practices but I'm not seeing anything in your description to indicate that you are actually practicing agile or following the Scrum framework.
Can anyone advise if scope increment (not replacement) by extension of schedule without additional cost is within Agile / Scrum delivery approach?
No it isn't because agile/Scrum delivery approach is based on incrementally delivering functionality so that conversations on changes to the delivered functionality or plans for future functionality take place. Then you continue to deliver until the customer finally says "this is enough". The customer would pay for work as it is delivered not based on a fixed scope or plan. Agile does not have fixed scope, fixed duration, fixed price as it is dependent on continuous assessment and adjustment until the customer gets what they want. You are building something the customer has asked for today to be delivered at some point in the future. Agile delivers what the customer wants until the customer says it is enough.
Agile does not have fixed scope, fixed duration, fixed price
Unfortunately, as a System Integrator (SI) outfit, we need to protect ourselves. So we cannot deliver until customer says it is enough without additional costs for additional work/EPIC etc. Hence, we estimate the capacity for the "iron triangle". Agile/Scrum is practiced (ceremonies, kanban etc) and there is Release 1 delivery in QA whereby the client can test and play around with apart from regular demos - which is part of the original contract.
Per my understanding of Agile, with fixed capacity, whatever new stories that needs to be in for delivery, another similar sized stories need to be replaced (but still kept in backlog). This also address the topic that what is scoped in for today, may not be needed in future when the development of that particular story is planned for a sprint.