I read an interesting article by a colleague of mine, Scott Francis, on technical debt in BPM projects (read it here). His article got me thinking about technical debt introduced through our project management practices.
Here's an example of what I'm talking about. Let's say you're working on capturing your user stories. You've gathered a group together and had a workshop set up for the afternoon to capture as many stories as possible. Tomorrow you plan on working with your product owner to prioritize the stories. During the afternoon session, someone mentions another user that isn't present that may have some user stories to contribute.
So here's where you decide if you're going to take on some debt. You could delay your prioritization meeting and go talk to this person tomorrow or you could decide to move forward according to your plan. If you move forward, you've just accumulated the debt of having other user stories added somewhere down the road that you will have to deal with.
Now you might be thinking this is agile, change is no problem. But do you know how big that debt is? It might be something insignificant or it might require some major refactoring in order to accommodate the new story.
That's the thing about technical debt. You're making a decision now in order to move things along that will have some consequence later. Do you know how big that consequence is going to be? Just like when you're taking out a mortgage on a new house, you want to make sure you know what you're getting yourself into.