Maintenance, production support, defects, performance issues are all in one bucket for us. We allocate one pair capacity for these for each iteration. That pair rotates on a daily basis, but does not work on iteration work. If there is a production issue, that pair works on the production issue. If there is no production issue, the pair will look for any performance cards that have been created. If there are no performance cards, then there are low priority defects which have been identified, but were not scheduled to be resolved, beyond that there are team productivity cards that this pair could play.

This pair rotates on a daily basis, so you do not loose the cross functional skill development for your team. Your capacity for work in the iteration does go down by one pair, but it is done in a controlled predictable manner that still allows you to schedule and commit to the iteration work for the other pairs without being concerned about interrupting the scheduled and committed work.

As far as the estimation issues are concerned, I have a couple of comments. First off if there is a drastic difference in estimates, simply averaging the two is not going to yield positive results. The developers will need to explain their rationale for the wild difference. Once the polar opposites have walked through their case, we have all the developers re-throw their estimate. It generally will converge to either the higher or lower side depending on how convincing the supporting arguments for each of the throws were. Even so, if you do not yet have agreement and the 13 holds strong while the rest of the team migrates to the lower end, the fact that you are pairing should mitigate the risk there. You may need developers to throw several times on an item if there is a large disparity in the estimate. We will not put a team estimate on a card until the whole team can come to a consensus. We will frequently ask the team if the estimates are subtle difference, if an average would suffice. Usually on a small difference, that is a perfectly legitimate solution. (+1) to the Cohn book on the subject, it would well be worth exploring. I would also like to underscore that these are estimates. And estimates by their nature will not and can not be precisely accurate.

The self-organizing, and continuous improvement mantra of agile means that your teams may evolve past the SCRUM baseline at some point. Respect the principles of continuous improvement and self organization, and I would be surprised if you were not able to overcome the challenges you identified in this post.

Tim Kadom

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