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

21398Re: 2nd thoughts .. Rsk-Mgmt and not much of Prince2

Expand Messages
  • dnicolet99
    May 8, 2007
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, srinivas chillara
      <ceezone@...> wrote:
      > However these exptended holidays of 3 people
      > during the same sprint was a nasty surprise. Actually
      > these people knew they were off on leave, jsut no one
      > thought it important enought to announce! (I know
      > amazing) These leaves were not taken into account
      > during the sprint planning. I think had we done a
      > quick risk assessment (ie rsk mgmt) we would have
      > planned better.

      You're right to say the problem is that the leave was not taken into
      consideration during sprint planning. However, it is not a question of
      risk management. It is not a business risk for employees to take
      leave. It's normal.

      What I've seen work well is for each team member to commit to a
      certain number of hours for the project as part of sprint planning. If
      we're working 40 hour weeks and we have 4 week sprints, then at most I
      can devote 160 hours to the project. If I'm planning 2 weeks of leave,
      then I must commit to 80 hours instead. That way, when the stories are
      sized and added to the sprint, the team won't overcommit.

      > Now I am writing a small (one or two pager) Scrum
      > implemnetation guide for the company, so they can
      > think of things to cover while they run their sprint.
      > Like, all team member udate on significant leaves to
      > they are about to be taken that month. I am calling
      > this a "Scrum-running Guide"
      > What's your opinion on this. Should I circulate such a
      > guide for the benifit of the company. To a wider
      > public, or is it not such a good idea? Will this make
      > Scrum more codified/prescriprive/"cookbookish"!?!

      It depends. If you try to include everything you can imagine and
      everything you've read about or heard about, then the guide will be
      justly ignored.

      If you include lessons learned in context, such as the problem of the
      "surprise" leave, then it will be relevant to your environment and
      people will find it helpful.

      I would also suggest that you make it a "living" document and update
      it after each retrospective or after "surprise" lessons are learned. I
      would further suggest that you never let the guide grow beyond one
      printed page in length. When you find you are just about to add an
      item that pushes the length over the one page limit, review the
      contents and look for items that can be removed. This will help ensure
      the guide remains relevant and useful while making it possible to post
      a copy on the wall of team rooms.

      > yours in doubt
      > Cheenie

      Yours doubtlessly,
    • Show all 20 messages in this topic