Retrospectives are great, but...

...they're not worth much if no action is taken afterwards. I haven't met many people who disagree that retrospectives provide a lot of value to the team. But without follow-up that value is often not realized, and if identified issues persist they can actually have a negative impact on the team.

In general, items that require follow-up need to be captured in a manner that will allow them to be followed up on. One method is to turn these items into new stories. I'm not always keen on this approach, since the items don't usually follow the spirit of the user story, which is to provide direct business value. Making the items technical stories often makes sense, as they can be factored into the iterations but don't meet the definition of providing business value.

A lot of the items that get brought up during retrospectives aren't related directly to development, which makes it hard to figure out where to put them. The issues list is a likely candidate. Another approach I've taken on some projects is to create a wall (like a story wall) which shows the retrospective action items and where they are in their lifecycle. Seeing a number of untouched items on the wall is a good indicator that the value is not being realized.

Another technique is to start future retrospectives with a recap of issues that came up in previous retrospectives, and where those issues stand. If the team sees that items are getting addressed, it could encourage them to participate in the retrospectives even more.

Lastly I just wanted to comment that the best situation is when you can get the team to decide on a resolution and take action right then at the retrospective. Not always possible (or advisable in some cases) but is a great example of realizing the value that retrospectives can bring.