First of all, you are talking about your role as a Scrum Product Owner. Most of the problems that you talk about have to be managed by the Scrum Master and/or the Team. Are you missing a Scrum Master? Your example developer is not managing himself nor the team does this. So the Scrum Master should have noticed this (e.g. the bombardment in Skype) and would have to work on this impediment. As a Scrum Master this problem would have raised in one of the first Daily Scrums.
To say it clear: Your Scrum Master didn’t do his job or you have made the big mistake to not have a Scrum Master!

Second: Never push the team. If you have a lot of other things to do, you need to put them into the planning process and they must end up in tasks within the stories built and delivered during a sprint! By pushing ‘other work’ into a running sprint you would violate Scrum rules. But: What I would suggest is to split maintenance and bug fixing / support tasks. Maintenance has to go to the product backlog and will be selected for the next sprint during the sprint planning (if importance is high enough, this is your part as a Product Owner). Bug fixing is different, it may be necessary to do this immediately. If this is the case, put the bug fix request as a new task card (perhaps use a differently colored card) on the task board into the current story as a highest priority task. The next available or capable team member has to select this task and work on it. Now the result is the following: of course you have more work in the story/sprint than initially planned but you have a task card for this. This will be your reminder in the retrospection. You will not sit there and ask yourself what went wrong; you have the reasons as cards on your board.
Finally your Team has to decide how many stories/story points they will select in the next sprint.
You will see that if you make bug fixing a type of impediment for the developers, they will self-organize this. In most of the projects quality will raise from sprint to sprint and the bug-fixing will decrease and the Team will not be ‘disturbed’ by bug-fixing anymore.

Third: Estimating in Scrum is much more about Story Points and NOT hours or days. This is a common mistake. Especially not number of day for experienced developers and number of days for dumb developers. I have the feeling that your Team is not selecting the right amount of work for them (as a Team not for each one as a individual). You should never pre-assign tasks to team members, nor should the team do this, because this member may become ill or is missing for any other reason. The Team
So please try to estimate as James has already suggested in his posting.

Apologies to all who read this useless post. I don’t agree with anything I’ve written there.

Well, it is like Google Adwords Editor, Microsoft WhatevertheforkIt’sCalledSimilarApp rolled into one and then hanging out with Yahoo.

It’s essentially useless. You can get the same results with other, free utilities.

So, don’t pay for this pile of crap. Unless you want to abuse their Adwords API quota.

To me the impediments are that

people feel obligated to ’stay available’ 100% of their daily time for supporting others.

estimating by hours doesn’t work. Many scrum teams have found this out which is why many of them use relative point estimating. I recommend getting Mike Cohn’s book “Agile Estimating and Planning” and maybe running through some excercises with the team.

GOod luck! Happy scrumming.

Regards,
Martin
Agilo for Scrum Developer

Today I experienced love increase towards Google Analytics (my love from the first report)

As I am walking from booth to booth her in eMetrics, no one really distracted my attention from my first love. Many beautiful eyes (blue, green!. gray) but nothing compare to my beloved ORANGE eyes!

My lover is more friendly, simple, focused, real, free,… name it…

I do respect all other products, do not understand me wrong, and I hope Google and its partners learn from all these cool tools and try to get the best of each tool and make it available in Google Analytics.

It is really nice to see E-Nor, EpikOne, and Analytics Pros active promoting Google Analytics in eMetrics and hope to see the rest of the GAACs in the near future.

Your GAAC friend from the Bay,
Allaedin Ezzedin
E-Nor

Hi Ron,

Ron Jeffries wrote:
> A long time ago I had a conversation with Kent in which he said that
> he had considered whether “Extreme Programming” should be
> trademarked. He thought that the primary tradeoff was between
> controlling what XP means, and broad adoption of the ideas (however
> weakly). He chose the latter.
>
> Those of us who complain from time to time that the notions of XP,
> or Agile, or Scrum get watered down need to remember that story.

I have no problems with Trademarks /per se/. They are a necessary part
of business. And I have no problem with companies saying things like,
“Scrum is a trademark. If you are going to use it, please adhere to the
following guidelines”. That’s pretty normal – if you want to use our
logo, here’s how we ask you use it.

But the difference between that and asking groups who are the grassroots
passionate users of Scrum that “Scrum User Group” is a trademark, and to
use it you need to sign a document – that’s over the line to me. That’s
what I wish they did not do. Offer guidelines – absolutely. Trademark
something that’s been in use for many years, and then come in after the
fact and require a legal document to be signed to use it – not so much.

That’s why I mentioned the Certified Scrum User Group Leader – I’m not
trying to be an ass, but merely point out that if you want to have that
much control over the groups, then offer that. I just wish they didn’t
send out letters willy nilly to the very people trying their hardest to
promoted and help the adoption of Scrum, and indirectly other agile
practices and techniques.

–
Cory Foy

And another thing – they seem to think that their opinion is gospel. Every single one of them. Logically that should be an impossibility, but they essentially repeat what anyone from Google says, and then stick by it like it’s their own fundamentally important doctrine.

If this GAAC group is ever going to end up as something which makes a valuable contribution to Google, somebody ought to firmly take a steel boot to the head of most of the people on the mailing list.