I believe with any documentation that the agile approach is a good one. Now, there are some misconceptions out there that agile means "no documentation or analysis at all" but that's not the case. The things I've read about agile say, "use what works." I take that to mean the document should be of length and detail commensurate to the task.
Templates can be helpful as a checklist, but I would not require every section to be filled out for small or low-risk changes. For a one line change, maybe you don't need a doc at all. I've never used a template for an impact analysis document, but I regularly deal with business requirements or technical specs. A template can be too restrictive; a good guideline is instead to consider who the audience will be. If it's for managers that are not technical, focus on the business justification for the change. If it's for technical people, provide a little background so a new person on the team won't be lost and give them enough to get going if they have to support the change. Also, if you want something even more friction-less and lightweight, don't use a doc at all, put it on a wiki.
Information to include:
- Brief description of issue
- Explain or show example of how defect is causing failure and/or inefficiency
- Include estimate of complexity
- Include estimate of cost and time for fix
That's a decent minimum. The other post highlighted some pretty heavy CMMi stuff from IBM; that's great if you have the time and resources for it (and when you're building systems for NASA where human life is at stake, then people better be serious about it) but for small teams you probably don't need to be that heavy. Be careful with the estimate, as always. Managers are prone to assuming an estimate is the actual.
Note that there are dangers in the agile approach. Some developers do think it means, "no docs needed, just start hacking away" (which might be OK in some situations). Also, others will take the latitude given the task and simply write really crappy docs that don't really help (not necessarily OK in most situations). Part of the problem is that writing well takes some effort, skill, and time; most of us are short on at least two of those things ;)
I've always been big on documentation because it proves you at least put in enough thought to qualify as having a plan. But in my old age I've also come to appreciate that too much documentation can itself become a maintenance hassle, and that not enough people care enough to keep documentation updated.