I’m a junior developer at a small SaaS company following a variation on Scrum. I have observed that stories often reach my team before the business requirements are fully fleshed out. The development team often brings tasks to near-completion only to learn that the product owner has just discovered a new, crucial requirement that forces us to rework our implementation. Other times, developers discover that recently deployed changes had first and second order effects on the business that were unanticipated (and unwanted) by the product owner and stakeholders that requested them. These revelations typically trigger a series of code "fixes" and various other kinds of remedies.

What, if anything, can I do to make sure that requirements are well-thought out before development starts and minimize wasted development effort?

  • 3
    This is the case more often than you may think. These development methodologies were created to lessen the effect of a moving target. Very rarely does a spec get created before a project starts that doesn't change significantly multiple times throughout development.
    – Ron Beyer
    Jun 24, 2017 at 22:06
  • @RonBeyer It depends if the changes in business requirements come from the outside (e.g. a customer/requestor explains their problem) or from the inside (scrum team changing their mind about what to build).
    – Kos
    Jun 25, 2017 at 11:39
  • When I (scrum master) see stories in the backlog of "my" team that are not fully clear, I simply reject them with a standard message. Whether a co-worker or my CEO wrote the story, they all learn pretty quickly when they realise we're simply not going to start working on it before it's cleared up. Jun 26, 2017 at 12:53

6 Answers 6


Ask questions.

In Scrum, the most natural opportunity for such conversations are backlog grooming meetings, where new or changed backlog items are estimated.

For instance if you're playing planning poker, your deck might contain the ? card. Play it whenever requirements are not precise enough for estimation, and ask follow-up questions. Likewise, if different people give wildly different estimates because they understood requirements differently, they should ask the PO for clarification.

Questions that do not affect implementation effort can be asked during the sprint (that's why the PO should be available for questions).

If in spite of your questions the PO continues to waver back and forth, that is his responsibility, not yours. In that case, make sure to make the wasted development time transparent by not accepting big requirement changes during the sprint, but ask the PO to write new stories for the changes. That way, the PO and any stakeholder reading the backlog can see that there is a requirement gathering problem, which increases the chances that it can be addressed.


Nothing, except do a good job, get promoted, become the product owner, and then produce well-thought out requirements.

To some degree this is what scrum is supposed to handle: The reality that some people don't know what they want until you show them something, and then they know what they want changed. That's why you do tiny tasks where changing them is not too much effort.

If there are side effects "that were unanticipated by product owner and stake holders", such side effects are often anticipated by good developers, and a good product owner would listen to feedback from developers. Bad product owners don't; this may also be a cultural problem.

  • 2
    To some degree this is what scrum is supposed to handle. Scrum/Agile still require to have a major line firmly defined and known, if you just perform a 90° turn on every runs, that won't do it.
    – Walfrat
    Jun 26, 2017 at 11:20

One thing you can do is try to shorten your rejection cycle. It's not clear from your question where the problems occur. But, for a specific example, Jakob Nielsen (https://www.nngroup.com/) [disclaimer: no relation, no benefit accrues to me] has published a newsletter for more than 10 years about user experience testing and UX design. He offers specific advice on how to prototype user interfaces, and how to do UX testing "on the cheap."

It might be the case that sitting down with someone from the user side and going through a prototype that is mocked up with a paper document and some cut out paper buttons and menus could save you considerable design/rework effort.

There are similar modeling options in other aspects of your software. For example, if your problems spring from accounting issues, maybe a primitive model built in a spreadsheet could make things go more smoothly. ("Oh, we have to apply sales tax? Okay, let's add that in at line 22.")

Honestly, it sounds like you guys are doing things slightly wrong, because it shouldn't be possible to get to the situation you describe. If your system owner is laying down requirements, you need to back them off and work more on user stories. If there's a user story, and someone tries to change it, THEN you challenge them: how could this user story have changed? Is this really a change to the user story, or is this a new user story with a slightly different circumstance?

I can imagine something like logging or auditing showing up late, where you spoke to the end users, got their stories straight, and didn't realize that every order entered required an audit entry. But invisible requirements are invisible. They won't change the user story, so it shouldn't be too hard to add those features.

  • 2
    And if you get pushback for wanting to do those things, keep track of how much dev time gets wasted by building the wrong thing and then throwing it out. Managers love hard numbers :)
    – Mel Reams
    Jun 26, 2017 at 2:37

First of all, you're not alone, and in a way being able to adapt your work when new elements pop up is exactly one of the reasons why framework like Scrum are used. That said, you have several ways to mitigate the problem:

  • Work on a Definition of Ready, agree with the PO on the definition of a minimum checklist a task or story needs to comply with in order to be eligible for work in the backlog. This may include something like fleshing out a sufficient number of Functional test cases. This naturally forces to think upfront of all the necessary acceptance criteria. If the task does not have enough elements to scope its perimeter at the beginning of the iteration it should not get into the iteration backlog.

  • Take time to analyze things before they get into your backlog, you may have enough experience or elements to pinpoint issues in time to fix them.

  • Report any inconsistency immediately to the PO, and keep track of them all along the project, so that you can have a discussion backed by some data on how to reduce them.

As for the unknown unknowns, well there's not much you can do upfront, but you could structure your work in a different way


I'm quite baffled by the obliviousness of some answers. "Nothing can be done" is the worst way of being professional in such cases.


The development team often brings tasks to near-completion only to learn that the product owner has just discovered a new, crucial requirement that forces us to rework our implementation.

Finish the task as specified originally and queue the revised version for the next sprint. The whole point of an agile approach is to lessen the impact of such a change by creating small iterations. You don't say how long your sprints are. If they are over 2 weeks then I would suggest to shorten them for this particular client until the quality of specs improves. This reduces time wasted without requiring cooperation of any external factors.

Other times, developers discover that recently deployed changes had first and second order effects on the business that were unanticipated (and unwanted) by the product owner and stakeholders that requested them.

This is more of a problem as it suggests that you have no one with a good understanding of the system. This should really be caught during the refinement stage of the tasks. If neither the customer nor the PO have the insight to watch out for these problems then you should involve the developers (or at least one developer with the necessary insight, like a "lead architect") in the refinement process. Dedicating more of the team's time to backlog grooming might help if your practices are good in principle but you lack the time to prepare enough tasks and then fill the remainder of your sprint backlog with unripe tasks.

Automated Testing might catch a few of these things as well (If you already test for A and B, then when you add requirement C you should get conflicts if implementing C throws off A and B)

Requiring more extensive acceptance criteria for a task might also help to provoke thought about the tasks consequences.


Try talking to your product owner. Tell him that the requirements are not clear to proceed with the design.

If the Product owner is able to solve it, proceed to the design meeting and so on.

Otherwise escalate your situation to the scrum master in the stand-up meeting so that your team gets to know the situation.

Waiting for the Retrospective meeting to raise this issue will be a waste of money and resources.

You wouldn't want to be the reason for the reduction in sprint velocity.

  • 1
    Waiting for the standup is also a waste of money and resources. Raise issues with your Scrummaster ASAP.
    – Erik
    Jun 26, 2017 at 10:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .