If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.

The Scrum suggets that we should only refine the top PBIs of the Product Backlog. The other PBIs are not refined, and thus the requirements related to these PBIs will be discovered lately in the project execution.

What is the Scrum's approach to this?

  • 2
    "If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement is very high." - citation needed.
    – Sarov
    Jun 28, 2021 at 18:17
  • 3
    Do you have an example of the kind of requirement you discover late that turns out very expensive? Usually, if it's important, it's on the radar, if it's expensive/complex, it's near the top of the backlog and if it's important, complex and previously unknown it's an outside change that a premade plan wouldn't have accounted for either. Your experience might vary, but this would be better answered with clearer examples I think.
    – Erik
    Jun 28, 2021 at 20:00
  • 1
    A change that invalidates all previous work might represent a sunk cost, but no more so with Scrum than in a project based on big, upfront planning. Iterative and JIT planning avoid (or at least limit) large sunk costs, so I think your question is based on a false premise.
    – Todd A. Jacobs
    Jun 28, 2021 at 22:25
  • 2
    @Erik Isn't that the point of Scrum? There will be outside changes that are unknown. The premade plan obviously wouldn't account for them. Since Scrum doesn't have a premade plan or fixed scope+time, you just insert the new requirement into the backlog in priority order. Whenever you decide that you have enough to release, you release. If you finished the new requirement before then, then some other, lower-priority stuff probably didn't get finished...no problem, it was lower priority and turned out to be not needed to release. Jun 29, 2021 at 16:59
  • 1
    ... In particular, if you start with a big, upfront plan then it might be tempting to put expensive/complex items near the top of the backlog, instead of purely sorting in order of priority. But maybe you spend a ton of time working on this expensive/complex item and it turns out it was a lower priority than 10 other easy items. If you did the 10 easy+important items and then said how much longer it would take for the expensive item, maybe the product owner would look at the product and decide it was good enough already, at least for initial release. Jun 29, 2021 at 17:01

4 Answers 4


If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.

In this statement you are saying that the cost of change is high (particularly late on in a project).

The agile approach recognises that change happens and so endeavours to reduce the cost of change.

This is the fundamental difference between the agile approach and traditional development:

Traditional development: Let's get really good at predicting what will happen (plan well)

Agile development: Let's get really good at responding to change (respond well)

  • 2
    "Plan well" vs "respond well". Indeed. Worth adding that the nature of software development doesn't usually play nice with a plan based approach, no matter how well you plan.
    – Bogdan
    Jun 29, 2021 at 10:58

Prioritisation, continuous delivery and review is the way to control delivery risk for any software development, not just when using Scrum. I can't agree with the first sentence of your question however. If work is ordered wisely then the most important and most risky or expensive work usually comes first, so the cost of unexpected work should tend to reduce as time goes on rather than increase. An experienced team will also try to identify for early refinement any items that have broad architectural impact or have lots of dependencies.

No method provides a guarantee against the unexpected but continuous delivery helps avoid nasty surprises by testing the product early and often. That's usually a much more reliable method than trusting early analysis alone to identify issues.

  • The problem is that if the PBI is not refined then it is hard to say whether it's risky or not, whether it requires an architectural impact or not.
    – Daniel
    Jun 28, 2021 at 19:02
  • You are right that there is risk in doing too little analysis up front. There is also risk in doing too much analysis if it unduly delays testing and delivery. Your team is in the best position to judge where to strike the right balance.
    – nvogel
    Jun 29, 2021 at 8:26

You say:

If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.

This can be true or can be false. It depends of the type of change you are referring to. I'm assuming a big change, or something lacking in an important way, or something that deviates in some way from what you have built up to that point. If this is the case, then yes, the change can be expensive. If it's just a requirement like others similar, then implementation will probably not be that high.

The way you phrased that first sentence and the rest of the question implies you are using a predictive approach, or a traditional approach in which you gather requirements at the beginning and then you build a plan to have then implemented. Only in that way can you talk about "the middle of the project".

If you are building the product in an agile way for example, you wouldn't know you are in the middle of the project because you are focusing on delivering value, not on timelines that tell you where you are in the project. However, this does not mean that using Agile or Scrum will guarantee that a requirement late in development will be cheap to implement. If you are building a white airplane and at some point you discover you need a submarine, you can't just chop off its wings, paint it black, and call it done. This kind of change will mess up your implementation no matter if you are using a traditional approach or an Agile one.

However, what Agile does, is that it allows you to figure out sooner that you need a submarine instead of an airplane, because you are incrementally and iteratively building stuff that you can collect feedback on and learn of what's needed, instead of assuming that you know everything from the beginning and you can specify it in requirements that won't change or are not lacking in some way. As already mentioned in the other answers, the Agile approach is different and reduces the chances of discovering something that can really be very expensive to implement at some point down the road.


From a sequential perspective, the idea that a requirement that is discovered later in the project is likely to be more expensive to address. Similarly, a defect found late after origination is also likely to be more expensive. This is because of how much work is done. Consider that in efforts run using sequential methods, you try to elicit all of the requirements early. Then, you create an architecture and design that addresses all of those requirements. Then you implement the selected design. A change, especially a new requirement or a modification to an existing requirement, requires analyzing the full set of requirements for issues and conflicts, then analyzing and updating the architecture and design, then updating the implementation, and then the tests. Changes ripple throughout each phase of the life cycle and all associated artifacts.

Scrum, and the majority of other agile methods, takes a different approach. There is just enough architecture and design to support the known requirements. The system evolves over time to accommodate new or modified requirements. That doesn't mean that a radically different requirement won't cause a large amount of rework, but the risk is reduced. By building incrementally and getting feedback to build what is perceived as the most important thing next, the chances of something that is very important but also very difficult to implement will be reduced. Any rework will be limited to the parts of the system already built, rather than rippling through many phases of development.

I would also add that as complexity increases, the cost of changing the functionality of the system does get more costly. However, using incremental design, keeping the design simple (think principles like KISS and YAGNI), and paying down technical debt early can make future changes less costly. The complexity that exists should shift more toward essential complexity as opposed to accidental complexity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.