I had a conversation with an agile team member recently who was frustrated that his customers didn’t know what they wanted. They kept changing their mind, and the team was spending a lot of time working on things that ended up discarded. As we talked, it became apparent that this was one of the reasons why agile had been chosen for the project in the first place. The solution was fairly complex and there wasn’t a clear consensus on what it should look like. That made it virtually impossible to define a full set of requirements ahead of time. It was considered far better to take an iterative approach so that the project team could build some of the functionality, gain feedback from the customer, and then adjust the solution based on that feedback.
But as this project proceeded, the customer was increasingly less sure about what they wanted. Not only were requirements being reprioritized frequently, there was a lot of churn in those requirements with additions and removals multiple times a week. Requirements that had been built and accepted were then rejected in later cycles or modified considerably, and in one situation there was even disagreement over what the solution was supposed to achieve. This person’s employer was new to agile and the team had been excited when they first learned that they were going to be adopting agile techniques, But now they were
Please log in or sign up below to read the rest of the article.