Here is a common question I get regularly. In this case it was Howard, a co-worker from the UK: “Probably a dumb question but...how do you define scope yet remain agile? Is it woolly wording, do you define it using some kind of abstraction or do you define in terms of number of iterations? The key being that, in my experience, most people what some idea of what they're getting up front, yet in remaining agile we want to defer that sort of decision until later.” This is not at all a dumb question because it identifies the key difference between agile and traditional project delivery. Here is my response to the questions. In my projects scope is a matter of defining this at the right abstraction level, or maybe more precise defining it without much detail. First thing you need is an concrete idea about the project’s scope boundaries. You can use the business case and vision for this purpose. They should provide the constrains with respect to for example business processes to suppo...
This is a personal professional notebook. In this blog I collect references to information on the Web which were in some way or another at some point in time interesting in my daily work as solution architect. I would like to emphasize this blog and its content depict a personal point of view.