What methods for measuring progress during a release sprint are effective

Question

EDIT TO IMPROVE CLARITY

Scrum suggests that you split your development into a number of sprints. Each sprint being a fixed duration. At the end of each sprint you ask the client if you should release the software. If they say yes, you perform a Release Sprint, during which you do all the tasks that you woud like to do contineously, but are too expensive, such as external user testing, performance load testing and sign off, burning CDs (if relevent), writing user centered documentation and so on

In my current project we have just performend our first release sprint. We found we lost a lot of the advantages of scrum such as the burndown (as a lot of things were fixing minor tweaks or temporaraly removing security from the site so the load testing could happen), a clear goal as to how much work was to be done next etc. Basically the relase tasks were too close to firefighting to be easaly trackable via normal scrum tools.

What methods have other people used for during a release sprint, and what pitfalls did you find that should be avoided?

Answer 1

We're using a kanban board with scrum. Each product item is represented by a post-it note on the whiteboard. Its really obvious during the daily standups where everyone is with each of their tasks, and we can see how many tickets we have queued up in the 'pending' area on the board compared to the 'done' area at the other end.

Answer 2

Actually, I prefer this tool. It does task-tracking, burndowns, burn-ups, and is useful for project notes.

But to answer the question, tracking hours-remaining on a burndown should still work. It'll still tell you whether you're going to get all your release-sprint tasks (bugs/tweaks) done in time for launch. If the answer is "not all of them", then it's time to get the product owner in to do some prioritisation, and kick some of the tasks out of the sprint.

Answer 3

Your goal should be to get to a point where you don't need a release sprint to deploy to production:) But with that said, what are you doing in your release sprint? There are still tasks to be done, but they are even more predictable than developing code. I've never seen a difference in how the burndown/planning works other than it usually involves adding people to the team from ops. That of course can be its own problem. Maybe you could give a quick idea of what a release sprint looks like in your organization.