Managing change requests and 'tweaks'
- We are in the final phases of a sprint to deploy products and are
running daily walkthroughs with all of the stakeholders. We are doing
a massive Site re-design so there are a lot of tweaks and changes.
Some are new requests, some are requests to change things to meet the
spec where the designers had incorrect direction and most of them are
little tweaks here and there where things don't look right.
The Scrum team isn't present for all of the walkthroughs as they are
trying to make the changes to get everything launch ready. This may
be a mistake in itself. My questions are:
1 - Should the team be present for walkthroughs?
If yes, any suggestions for time spent and frequency would be great.
2 - How should the change requests be captured and who should do this?
We started with the Scrum Master taking notes and as he was also
driving the presentation I suggested the Product Owner capture the
changes into a spreadsheet as we went. We also started to capture the
requestor as we had found that new changes were being made that others
didn't agree with and no-one knew who had suggested them making it
difficult to track the logic behind them. The Product Owner can then
rank what they think is going to bring the highest business value and
what would block launch
Or another way to do this (and this might be best although harder to
track) is to get the team members to take the changes directly and
write them on a card so they can do them. Maybe someone can track
them overall as well? It's getting a little heavy and I don't want to
lose things in translation.
3 - Who should drive the presentation while projecting?
We have the Scrum Master doing this - I'm wondering if the Product
Owner should direct what they want to see otherwise the Scrum Master
might influence the walkthrough by going over the same path they know
works rather than the way a new user might go through it and we might
not uncover as many bugs as we would otherwise.
Any suggestions would be greatly appreciated.