Is the Team following Scrum if they do this....?

In my opinion, it depends. I may be wrong though - feel free to correct me.

The Sprint timebox is fixed, but other timeboxes (e.g. Sprint Planning, backlog refinement) are a guideline and not a hard rule.

I think the role in Scrum is "Development Team Member". But I've always heard people refer to each other as Developers or Testers instead of Development Team Member so I don't know about that one.

And as far as I know, velocity is not mentioned in the Scrum guide, so I think it's an optional but effective way to forecast Sprints.

If a team exceeds the timebox of any Scrum Event occassionally does it mean they are not following Scrum?

It depends.

All of the Scrum Events - the Sprint, the Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective are timeboxed. Of these, I believe that the Sprint has the most firm timebox. For a new team adopting Scrum initially, I can understand overrunning the timeboxes as they learn effective management of the time allocated to each event. I would look for teams that are aware of the timeboxes and striving to stay within them, and for less mature teams, Scrum Masters who are slightly more actively involved in reminding and enforcing the timeboxes.

I suppose that you could make an argument that learning about the events should take place outside of the events, but I am unconvinced by that argument and I personally prefer just-in-time training and education. Therefore, small overruns may be more likely in less mature teams or teams in the midst of a most extensive experiment in how to execute a particular event.

The other thing to consider is that the Sprint Planning, Sprint Review, and Sprint Retrospective are timeboxed based on a 4 week / 1 month Sprint and are "usually shorter" for shorter Sprints. Most people, in my experiences and from my reading, aren't using 4 week Sprints. I would find it difficult, even for less mature teams, to spend more than 8 hours in Sprint Planning or more than 4 hours in Sprint Review or 3 hours in Sprint Retrospective.

If a team uses more than 10% of their capacity for backlog refinement then are they following Scrum?

Absolutely!

The Scrum Guide states that refinement activities "usually consumes no more than 10% of the capacity of the Development Team". Unlike the events, it's not a timebox. The time varies, but I would find 10% to be a good floor. I start asking questions if a team is spending less than this for several Sprints in a row and spending more from time to time isn't a problem. However, excessive time in refinement, especially over multiple Sprints, could be a sign of some issues such as poor refinement processes or a very unstable Product Backlog.

If a team has members referring to each other as developer or tester because of their skills, even though they are aware that the only title in the Development Team is Developer, then are they following Scrum?

I'm torn by this.

On one hand, organizations have titles. They relate to compensation, career development, management structure - things that fall outside of Scrum. It makes sense to have various titles or grades for people who take on the role of Development Team member, from an organizational management perspective. However, it's important to recognize the fact that these titles and grades shouldn't matter within the Scrum Team - everyone's opinions, thoughts, knowledge, and expertise are valued and there's a high level of professionalism.

Rather than focusing on titles or what people call each other, I'd look at silos. Does the team have unnecessary hand-offs or siloing work to people of certain titles? If so, I would say that the team is not embracing Scrum and cross-functional, self-organizing Development Teams.

If we don't use velocity as a metric, does it mean we're not following Scrum?

The word "velocity" does not appear anywhere in the Scrum Guide. In fact, Scrum does not define any metrics.

Scrum isn’t something to be followed at all, in so far as it is not a methodology with prescribed steps. It’s a framework to be implemented as defined in the Scrum Guide. Teams should actively search for better ways of doing so in their context. If they don’t you could say that their implementation has stalled in some way.

Let me add my $0.02 on some specifics

If a team exceeds the timebox of any Scrum Event occassionally does it mean they are not following Scrum?

Sure, why not? The Scrum Master teaches timeboxing, but a timebox can go wrong for any number of legitimate reasons. Now, not recognizing that, not trying to mitigate it, or not caring about timeboxing at all, that would be "not following Scrum" (as far as that's even actually a thing :) )

If a team has members referring to each other as developer or tester because of their skills, even though they are aware that the only title in the Development Team is Developer, then are they following Scrum?

As a member of a Scrum Team, you are either Scrum Master, Product Owner or member of the Development Team. In my opinion, that does not in any way suggest that you can't or shouldn't recognize specialisms. In fact, wouldn't recognizing specialisms be essential for guarding cross-functionality?

Everyone above has given great answers with good details. So in a very unusual move, I am going to keep this short.

The answer to all of your questions is no.  As @Ian pointed out Scrum is a framework, the process you put in place is completely up to you.  I have no problem with events going long as long as they are honoring the purpose of said event. As many said, the only exception I have to my rule is the Sprint.  That is very important to keep to a set schedule.  

On the job titles topic, truth is all company's have job titles. I coach my teams to recognize the job titles as areas of expertise but that anyone on the team should be willing to do any work that is needed at the time that they have availability. They should not do only the work that applies to their job title.  In the long run it benefits everyone to obtain cross expertise knowledge. 

The answer to all of your questions is no.

@Daniel Wilhite, When you say "No", as in, its okay to go past the time-box or not okay to go past the time-box.

 I have no problem with events going long as long as they are honoring the purpose of said event. 

Isn't it one of the rules of Scrum to keep the events within the time-box? I agree that in reality sometimes we do go past the time-boxes and we have misses here and there. Is it still Scrum even if we have the misses?

Scrum isn’t something to be followed at all, in so far as it is not a methodology with prescribed steps.

The Daily Scrum is a 15-minute time-boxed event for the Development Team.

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.

@Ian Mitchell, @Daniel Wilhite, The last two lines are from the Scrum Guide. As an example, if exceeding 15 minutes is okay and can still be called Scrum, wouldn't it be better to re-word it to something like "The Daily Scrum is an event for the Development Team and it is recommended to not go over the time-box of 15 minutes" as opposed to the current verbiage.

I guess I am trying to gain clarity into the language used in the guide. Again, taking this as example, is it an immutable rule or is just a guideline? How do we differentiate between similar things within the Scrum Guide that are immutable vs. flexible?

taking this as example, is it an immutable rule or is just a guideline?

Both. The 15 minute timebox ’s one of the rules of the Scrum Framework and those rules are immutable. If any are changed then the result is not Scrum.

It is also a guideline. If a rule isn’t right in your context then don’t implement it. Scrum does not require you to do the wrong thing. However if any of the rules, artifacts, and events of Scrum are changed, regardless of the justification for doing so, you should not call the result Scrum.

When it comes to implementing the rules, I think that there's a difference between planning on breaking the rules of the framework and slipping a little. If you plan for 30 minute Daily Scrums, you are knowingly breaking the rules. But I think that's different than a team, for some reason, needing a few extra minutes to finish the intent of the event. The same applies to any of the events, but I do think that there's more room for course correction in the longer events as you find out that you aren't making appropriate progress. I don't think that it's appropriate to set a timer at the start of the event and just abruptly terminate it when the time expires.

Also, I think that this difference matters. If you are calling what you are doing Scrum, you should know the rules of Scrum and that the rules are immutable. If you knowingly plan on breaking the rules, you aren't doing Scrum and shouldn't call it Scrum since that doesn't help people understand. But if you are making an effort to play within the rules, then by all means, call what you are doing Scrum, even if there are sometimes flags on the play.

I should have clarified this statement a bit more.

I have no problem with events going long as long as they are honoring the purpose of said event.

I don't have a problem with this as long as it is occurs seldom. But if this becomes frequent or consistent I take that as an opportunity to delve deeper into why and help the team find ways to address the root cause.  As @Ian and @Thomas point out if you are not following the rules you are not doing Scrum.  But reality is that you may not be able to follow the rules in some situations.  Does that mean you aren't following Scrum? To me "yes" if you don't take the opportunity to inspect and adapt. If you are inspecting and adapting based on rule exceptions then no and you should not call it Scrum. Inspect and adapt is more than a rule, it is a basic building block for Scrum.

Oops.

Change 

To me "yes" if you don't take the opportunity to inspect and adapt. If you are inspecting and adapting based on rule exceptions then no and you should not call it Scrum.

to 

To me yes if you don't take the opportunity to inspect and adapt and you should not call it Scrum. If you are inspecting and adapting based on rule exceptions then no and you can still call it Scrum.

Ian, Dan, Thomas, Thanks for your inputs, I think this was a good discussion.

If you plan for 30 minute Daily Scrums, you are knowingly breaking the rules.

Maybe it's nitpicking, but I would avoid putting it like this, as it suggests a (derogatory) value judgement. As I see it, you're merely choosing to not use the Scrum framework as described in the Scrum Guide.

But I think that's different than a team, for some reason, needing a few extra minutes to finish the intent of the event.

Right. Teacher/Change Agent, not Scrum Police :)

Maybe it's nitpicking, but I would avoid putting it like this, as it suggests a (derogatory) value judgement. As I see it, you're merely choosing to not use the Scrum framework as described in the Scrum Guide.

No - it's an accurate assessment.

It's OK to choose to not use the Scrum framework. However, if you call your daily coordination and replanning events "Daily Scrums", you are tying yourself to the Scrum framework and rules. If you aren't using Scrum, don't use the Scrum terms for things - it only will confuse people if you try to seek help from others.

Words and communication are vitally important for success.

If a team exceeds the timebox of any Scrum Event occassionally does it mean they are not following Scrum?

As you termed it 'occasionally' , i would assume reason could be sharing of an important information or purpose of event not met within the defined time box. So, if this happens not so often then as per me it should be ok else it needs inspection.

If a team uses more than 10% of their capacity for backlog refinement then are they following Scrum?

Does using more than 10% of Dev capacity for backlog refinement endangers your Sprint goal ? 

If a team has members referring to each other as developer or tester because of their skills, even though they are aware that the only title in the Development Team is Developer, then are they following Scrum?

I would not mind till the time they regard the scrum values. Team have joint responsibility in meeting the Sprint Goal. If they are collaborating in achieving the goal and performing every possible task when needed everything is fine. At the end every team member has at least 1 special skill but that should not be a bottleneck rather used as an opportunity for cross skilling. 

If we don't use velocity as a metric, does it mean we're not following Scrum?

Scrum Guide has no reference to velocity. But i would suggest to use this only for forecast metric and not performance metric.