21398Re: 2nd thoughts .. Rsk-Mgmt and not much of Prince2
- May 8, 2007--- In email@example.com, srinivas chillara
>You're right to say the problem is that the leave was not taken into
> 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.
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.
>It depends. If you try to include everything you can imagine and
> 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"!?!
everything you've read about or heard about, then the guide will be
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
- << Previous post in topic Next post in topic >>