We're currently doing an agile project where the customer is less agile than what we actually hoped for (he stays with waterfall). Also, while an official requirements specification exists, it is unfortunately not updated by the client (timing problems, whatever), so, our current process to get information we need looks like this:

  • to get the requirements right we collect questions to the "epics" we identified in a Wiki (Confluence)
  • for each epic, we export these questions to a Word file and send them to the customer
  • the customer comments on these questions and sends them back
  • we copy-over the comments from the Word file back into the Wiki and further comment on them or close the questions, eventually we send updated epic exports back to the client

The reason why we try to keep these information in the Wiki is because we would like to have one central, searchable place where all the project requirements are clarified and described in detail (no Word document hell). Furthermore, we currently write our system specification in the same Wiki as well, which gives us the ability to reference customer answers / requirements to the functional requirements we define and much more.

Obviously though there is at least one problem with this approach: The hand-copying of answers and the exporting of question catalogues over and over again. This, paired with the problem that some kind of "external" agreed document must always exist to reference later on in case stuff goes wrong, is a major headache for us.

I know people used Action Item lists for these kind of things in the past, but this does not at all fit our information finding expectations. On the other hand, a Wiki, by its nature being able to be edited at any time, surely will also not match the "agreed document" requirement.

So, what are some valid techniques to do these things better (proper tool support even?!) or have you already ran away after you read the first paragraph of this question?

  • The question as currently written sounds like you are soliciting for services; could you make the question more explcit? Could you attach the coordination document (or explicity import it) to the wiki page ?
    – MCW
    Commented Mar 26, 2014 at 12:24
  • No, I'm not soliciting for services; I'm looking for best practices from other people who faced similar problems managing requirements with "waterfall" customers and agile workflows. Commented Mar 26, 2014 at 14:30
  • 3
    Relevant but not an answer: you can't do agile within waterfall because there's no point allowing/expecting change within a framework that doesn't allow it. I suspect that the problems you are facing now are simply the tip of the iceberg.
    – Sklivvz
    Commented Mar 26, 2014 at 17:21
  • @Sklivvz Yep, I know, more problems are ahead. We're basically doing agile in a walled garden, to satisfy our own planning needs. I'm a strong agile believer, but some customers just cannot be convinced to follow the lead. Commented Mar 26, 2014 at 19:46
  • Putting it simply, you don't. It's not a matter of following the lead - sometimes, the client is used / must use waterfall (like big companies that requires tons of red tape). Think the other way round: would sound reasonable to have someone trying to put your agile projects into a Waterfall model? I believe both models have pros and cons... there's no much value in trying to have a one-size-fits-all model.
    – Tiago Cardoso
    Commented Mar 27, 2014 at 1:39

2 Answers 2


This is a common problem with most methodologies. Tracking and documenting changing requirements is difficult. Both the customer and development team need to be award of changes to the requirements. And both will likely be driving changes to the requirements. If the client has done Big Upfront Design, rather than Waterfall, they are less likely to drive changes.

As you are finding, the development team is generating requests for clarifications of the requirements. The client may also have changing requirements. This is commonly dealt with by a change control process.

You may find keeping the documents flowing between the team and the client in a text format works better. Doing the communication using email messages may make the transfer of information flow more easily. Depending on the answers received, it may be appropriate to cut and paste the answer into the requirements document. Other changes may result in edits to the requirements. In any case, you should be able to trace the current requirements to the original requirements, and any approved changes.

Asking for clarification more frequently may help reduce the friction in the change process. Adding the changes and responses to a bug/issue/task tracking system may also help in a number of ways. With the appropriate work flow you will be able to track the changes through their life cycle. It may be easier to get the client to join use the issue tracking tool than update the wiki.

  • That was one of my options here as well, we have an issue tracker (Jira) set up, that will be used during development later on. My thought was that maybe somebody already tried to negotiate / clarify requirements with the help of an issue tracker and would tell me if that is working well (wrt tracability for example) or not (nightmare, because similar requirements are spread between many tickets and nobody sees through it after some time). Commented Mar 27, 2014 at 12:58
  • @ThomasKeller The workflow should be to update the documentation based on issue response before closing the issue. If you can link the requirements document to the issue, it may allow you to determine which requirements documents have the most churn. Referencing the issue in the requirements update comment would be a good idea as well.
    – BillThor
    Commented Mar 28, 2014 at 12:33

I'm still not sure that I understand the question/problem, and @skilwz's comment leads me to believe that this might be an X:Y problem. There is going to be turbulence & friction if your customer is committed to waterfall, and you're committed to agile. The real problem may be differing conceptions of how to manage change and scope. I also suspect that this is a violation of CodeGnome's law - you're masking the technological implementation rather than the core problem. (Neither of those comments are a criticism of you; the situation is what it is, and you're trying to navigate your way through it as best you can.)

As I understand it, you're managing change, but your customer is not participating in the change management process. Some alarm bells go off in my mind at that point that have nothing to do with agile/waterfall/whatever. The customer's detachment from change and scope management concern me at a fundamental level. If it were possible to resolve that problem, I'm sure you'd have done so, so let's proceed on the assumption that you don't have the option to affect that problem.

Proceeding on that assumption, you've taken the defensive step of formally requesting your customer's participation in change management, and formally recording the customer's input. I think there are two goals

  1. Be effective in incorporating the customer's input into the change control process despite the customer's reluctance.
  2. Ensure that you've got formal traceability from customer input to requirements.

The desire for formal traceability raises the volume of the warning bells, but there is nothing we can do about that.

My first priority would be to make sure that the team understands the problem and the solution. If the team doesn't understand the problem, not amount of sophistication in the technological implementation will matter.

Then I'd import or attach the customer's response document (what I would call the "epic word document") to the wiki page. (depending on what your wiki supports), and build links from your requirements to his comments.

Sorry for the longwinded reply, but the peripheral issues concern me more than the core question.

  • I'd only do a tiny change on this: "you're masking the technological implementation rather than the core problem". +1!
    – Tiago Cardoso
    Commented Mar 27, 2014 at 1:33
  • Made the suggested change.
    – MCW
    Commented Mar 27, 2014 at 11:04
  • Haha, apologies! I meant that, from my point of view, it'd be masking... but that was just me :D
    – Tiago Cardoso
    Commented Mar 27, 2014 at 11:20
  • 1
    Thanks for your answer, its not what I expected from my question (and doesn't solve my immediate problem), but surely it was helpful for me getting a second sight on the project. We have our own bells ringing and for now have settled down with the customer to a more formal way of communicating with each other. This is not ideal, and it is time consuming, but it works. I'm used to do 100% agile projects over the last years (with happy customers), so the blow back to waterfall came totally unexpected for me as well, so I had to adapt quickly. Commented Mar 27, 2014 at 12:54

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.