I am working on a project. My client has asked for a requirement that slightly deviates from the initial terms and conditions agreement. I think it's a change request. In Scrum, how do I handle a change request? Do I put the change request into the Product Backlog and then prioritize?
Add a comment
|
8 Answers
TL;DR
The original question was tagged Scrum, so my answer will focus on how Scrum expects routine and non-routine changes to be managed. In brief, Scrum embraces change, but encourages the Product Owner to plan refinements for future iterations whenever possible.
By treating refinements as new work, the framework encourages ongoing collaboration between the Scrum Team and stakeholders. It also encourages stakeholders to take responsibility for product planning in a less myopic way by making cost of delay and cost of planning disruption explicit parts of the value discussion. This prevents the rubric of "business value" from becoming a very heavy club for stakeholders to beat the Development Team with, and forces pro-and-con discussions of business value to the forefront of Product Backlog discussions rather than leaving them as hand-waving exercises where the squeakiest wheels will be given the highest priority regardless of cost to the project or the Development Team.
Change Management Options in Scrum
In Scrum, frequent-but-controlled change is baked into the framework's empirical control process. Change is expected over the life of a project, but the framework expects refinements to be made at iteration boundaries. An escape hatch for more profound changes to scope or strategic direction is also provided, but the costs for such changes are explicitly charged to the project.
Refinements
Scrum is an iterative methodology. Changes are expected, but the idea is that most changes represent small refinements to work that's come before. For example, "a requirement that slightly deviates from the initial terms and conditions" is a refinement of a previously-planned or -implemented feature, rather than some radical new direction for the product.
Refinements that don't jeopardize the current Sprint Goal are generally treated as new work to be planned for a future Sprint. Since the Development Team has already planned the work for the current Sprint, refinements are placed onto the Product Backlog to be estimated, prioritized, and planned the same way as any other work in Scrum. This is the very essence of iterative development!
This ensures that the overall value of the current Sprint Goal can still be delivered. During the Sprint Review, the Product Owner and customer can determine whether the delivered increment is good enough to keep as-is, or whether the potential value of the proposed refinement is worth allocating capacity to in future Sprints. The Product Owner can then prioritize the refinement accordingly.
Another benefit of this approach is that change within a Sprint is minimized. By encouraging changes at iteration boundaries, the framework leverages a predictable inspect-and-adapt cycle to provide routine inflection points to stakeholders. Stakeholders don't have to wait indefinitely for their changes to be considered, because they know exactly when the next Backlog Refinement and Sprint Review will be. It also gives the Product Owner the leverage to determine whether a changed requirement is really so urgent for the business that it can't wait for the next beat of a well-defined development cadence.
In many organizations, stakeholders substitute magic words like abracadabra with "business value" in order to push through disruptive changes without charging the cost to the project or fully weighing the potential cost of the change. Encouraging change at predictable inflection points ensures that the stakeholders bear some of the responsibility for planning and thoughtful change control, and this generally reflects a careful balance between flexibility and disruption.
Escape Hatch for Profound Change
Despite the foregoing, there are times when a change is either so urgent that it truly can't wait for the next iterative cycle. Scrum doesn't prevent such changes; it simply makes the cost of those changes explicit and visible to the stakeholders.
If there is a change that would invalidate the current Sprint Goal, or that can't wait until the next Sprint to be prioritized at the top of the Product Backlog, the Product Owner can cancel the current Sprint:
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.
When a Sprint is cancelled, any completed and "Done" Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.
The last part is especially important. It forces the project's stakeholders to treat disruptive change as a visible cost to the project rather than wishing the costs into the cornfield, or hand-waving the disruption to the Development Team's current increment of work. It forces the Product Owner to ask the business whether the cost of disruption outweighs the cost of delay, and to consider potential impacts to the agile release plan and the lead time of other items on the Product Backlog.
By making these considerations visible, the framework prevents hidden work and hidden costs from creating drag on the project. It also fosters collaboration and communication with stakeholders, and often leads to tighter and more effective feedback loops for each iteration.
Since only the Product Owner can actually cancel the Sprint, it ensures that such drastic changes are controlled while still allowing them to be made when truly necessary. In other words, even drastic changes can be made within the Scrum framework, provided that the costs are visibly charged against the project and any changes to the project plan are visible to everyone.
CodeGnome's Law of Transparency says "No invisible work, ever!" This framework feature enforces that, without preventing the business from pivoting when required. It provides rigor without inflexibility, and that's what makes it agile.
answered Nov 18, 2019 at 14:44
Short answer is: yes. Backlogs are assumed to be emergent and are expected to change and be re-prioritized often.
Although Agile is setup to expect and to handle change, there isn't a great deal of detail in Agile frameworks about how to handle contract changes.
The assumption is that in an Agile delivery some mechanism will be put in place to deal with significant changes (i.e. change requests). For example, some organisations will work using 'time & materials' where any changes are naturally covered by the cost of the extra work. Other organisations may use contracts that are built to work with Agile, where scope is designed to be flexible.
As such, I'm afraid the answer to your question isn't clearly defined as it will depend on the contractual agreement you have.
answered Nov 18, 2019 at 9:10
-
2I think this is a good answer, but I suspect that the OP really meant some sort of up-front planning document (incorporated into the client contract or not), rather than the contracting process itself. I agree that the use of "terms and conditions" in the OP was confusing, but would say that a contract-management question is simply off-topic if it turns out that's what was really meant.– Todd A. Jacobs ♦Nov 18, 2019 at 14:48
-
I based my answer on when I worked at a consultancy that used a mixture of traditional project management and Scrum. There were all sorts of different approaches to handling change requests that varied from customer to customer. When using time & materials we usually just added a CR to the product backlog. However, on fixed price contracts we sometimes kept CRs out of the backlog and billed them in a different way. I guess my point is I find it hard to see how you separate out the contractual from the process. CRs are inherently a contractual thing. Nov 18, 2019 at 15:03
In my experience it is best to keep the current sprint backlog relatively static, but if the new requirement cannot wait until the next sprint, I believe the only sensible way to deal with an additional requirement is to trade it with another similar sized requirement.
If you allow things to be added you run the risk of the whole process of scrums and/or sprints running into disrepair longer term.
We allocate 10% as a buffer time to accommodate any urgent requests or change requests that come after the start of the sprint. Obviously it would mean re estimation and realignment of priorities. Anything more than 10% we move out other tasks with similar estimates.
I know it defeats the purpose of having the sprint if you resuffle the tasks midway, but business is our priority and we can't compromise business at the cost of methodology.
One of the main things each Scrum Master deals with is protecting the Team from incoming work to the active Sprint. As a Scrum Master, your role is to help your Team stay focused on the active Sprint and protect them from incoming requests that might put that focus at risk.
Knowing how to deal with those incoming requests from the beginning will be a huge help for you. I created a short 2 min video that shows how to deal with that scenario: Scrum Master Tips: How to handle requests coming to the Scrum Master directly.
-
I think this answer would be better if it had the key points of the video in your answer. External links go stale, videos get taken down, etc Nov 26, 2021 at 14:11
In my experience it depends on a lot factors, if the task is out of scope, it will be considered when all tasks and items on the backlog has been cleared. If it is part of scope and was not considered before then it can be added on the backlog and be done in the next sprint.
"I just started the car. But, as soon as I did so, I wished that the engine should be located in the back. Is this a problem?"
