One of the developers where I sit was re-jigging his project’s Kanban board the other day. He remarked on how all our boards have “Change Request” as one of the available cards. And then said something quite interesting: “When you think about it, there is no point in having Change Request cards as in Agile you would only ever have new features. There isn’t really any concept of a “change”. It’s a waterfall idea – where you are deviating from some upfront specification”.

And I think he has a point. I have to say the fact we have “Change Request” cards has never really bothered me. But equally, it is often difficult to choose between “new” and “change”. So perhaps he’s on to something, and the reason it is hard to choose is because “change” shouldn’t be there at all.

At the moment, on my specific project “change” generally means we are altering the behaviour of something, but it is done via configuration or reference data. You could argue the “feature” is unaltered but behaves slightly differently. Further, there is involvement from IT to make the change. It isn’t something the users can do themselves.

It’s an interesting question, and I don’t have an answer to it.

« »