The product backlog's back side

When you participate in scrum training sessions or when you read about scrum in all those books people like to sell, the product backlog is described as a list of stuff that need to be done. Well, that's the front page of the product backlog. And one of the needs.

But you also have the backside of the product backlog - what you have accomplished. I've sometimes seen these fancy project burn downs or product burn downs and they are a part of this question: what we have done. But the question is larger than that, especially for a project where muliple versions of a software is being used.

I'm talking release notes, delivery notes and information in the line of questions as "when did we change that stuff?" and "since I'm doing some acceptance testing, what should I be testing"?

When I came back from this summer, I found that the backside of my product backlog haden't been given any love. Everyone was focusing on getting stuff done that they didn't take really good care to documenting what had been done and it's taken me almost a month getting things sorted out - which bugs had been fixed, outdated and changed behaviour?

When you form your product backlog, think about your needs for history: do you want to dig into some code to know when a feature was implemented or a behaviour changed? I'm pretty bad at reading code so I'm happy for my delivery notes. And so is our customer operations. Find your objectives for the backside of your product backlog and do so before the questions start popping up. Fixing the backside is a small task if you do it regulary, but fixing it afterwards is boring, a hazzle and takes a lot of time.