Loading ...
Sorry, an error occurred while loading the content.

Managing change requests and 'tweaks'

Expand Messages
  • gabby_robertson
    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
    Message 1 of 1 , May 27, 2004
    • 0 Attachment
      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.