Tracking meetings and help outside of teams in velocity

Why is collaboration thought of as being drag?

In addition to the fine question of Ian... what is your PO's view on Value? Why is there a "drag force ticket" (Who came up with that name????) in the first place? Why are Scrum Events not part of / seen as "work" in your "work day", and finally, since the Dev Team is accountable for the Sprint Backlog, where is this "PO drag force ticket" residing? (and if in the Sprint backlog, how does the dev team feel about this?)

Also, why do you have a "ticket for Scrum meetings"?

should I include the drag force ticket in their velocity? 

My opinion is "Should not", you should create a ticket for "Other effort" or "Management" then put drag force ticket into.

The PO came up with the idea of the 'drag force' ticket idea. That was in place before I became Scrum Master. My understanding of the purpose of the ticket is they didn't know where to put time they used for helping other teams and helping team members questions and issues. I was mistaken when I said there is a scrum meeting ticket. As I mentioned, we use an average 6.5 hour work day- the remainder 1.5 hours is what's for scrum meetings, company meetings, etc. 

Where I'm struggling is if the time in the drag force ticket should be counted in velocity. 

In my opinion, it is Work Done, so yes, it should be counted towards velocity.

But still, wy do you have these practices in place? What do you think of this, and the team? It was there before you should never be a valid reason to keep it there. Did you raise questions?

My understanding of the purpose of the ticket is they didn't know where to put time they used for helping other teams and helping team members questions and issues

My suspicions are perhaps confirmed.   To me, it sounds like there is still a requirement for team members to account for their time, as if the amount of time spent is either a proxy for value, or can be used as a "hammer" in the event some effort takes longer than anticipated.

Kristen, why do you believe  your organization has such a level of mistrust for the teams tasked with delivering value?

@Xander- I believe it should be counted as work done, thus added to velocity. Candidly, this team has been difficult to work with. They haven't established trust in me yet and the PO hasn't been overwhelmingly supportive. The previous S.M. didn't take care of his responsibilities as S.M, so the PO picked them up. Now I'm having a difficult time with her letting me take them over. One of the developers on the team doesn't think 'it's fair' to be counted in velocity since it's not development work. He is rather outspoken and is probably my toughest critic. If he isn't satisfied with my answer, he goes to our Program Manager. Thankfully our Program Manager and I are on the same page. 

@Timothy- I don't really see it as a mistrust. In fact, the company is rather relaxed in that regard. What I've learned in everyone's answers to my question is I need to investigate why this ticket was even started. 

Is that "drag force" takes a lot of hours every sprint? If it only takes 5-15 minutes to help, i don't think you need to put it as a ticket. If it takes 2 hours of your team every day then you need to check with your organisation on how to improve on your process probably.

this team has been difficult to work with

Congratz! How cool to have an actual challenge given to you ;) Embrace this!

Now I'm having a difficult time with her letting me take them over

make sure roles and responsibilities are clear to her and the team (and whay this is important to be clear!)

doesn't think 'it's fair' to be counted in velocity since it's not development work

And this is an important issue to address! Oldschool thinking is that development word is the only "real" work. It prevents teams in becomming self-organized. I always say: if dev work is the only real work, you would be out of a job, since nothing will be refined, right? Delivering stories from A to Z (from business whish to done increment) takes much more than only dev work.

What I've learned in everyone's answers to my question is I need to investigate why this ticket was even started. 

Yes, you seem to be working in a culture where people feel the need to account for their time.   Interesting that this practice still holds sway over team members despite the organization not really pushing it.   

I'd be curious to understand what their motivation is around accounting for time.   What benefit/value do they derive from it?   What are possible alternatives to this practice?

Looks like they are using the ticket management tool (if other than JIRA) for time tracking tool and not to tracking 'business value'

Or

they want to show their 'management' on where are they spending their time on a daily basis. Maybe an opportunity to educate them about INVEST model (specially the 'V')

Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.

Then the question is => does the daily scrum, PB planning,  Retro meeting etc events  all have story points? 

In addition to the advice above, I'd like to flag this approach

As I mentioned, we use an average 6.5 hour work day- the remainder 1.5 hours is what's for scrum meetings, company meetings, etc.

The work day is usually 8 hours long. Of those, one's probably productive 3/4s. Add lunch (even breakfast), (coffee) chats, restroom breaks - you see where I'm going.

I'm confused by your choice to consider the meetings (scrum meetings, company meetings) outside the "work day". Meetings are work. Now, if we speak about pure "coding" time, not even 6 hours are covered by that. There are a lot of things that go against coding, more specifically, to create the conditions for the coding to "happen".

Every metric should have a supporting use case. If you don't know why you're measuring it, don't capture it.

Use that mindset for velocity as well as the drag ticket, or anything else that's being measured which is not directly related to delivering functionality. All of these metrics are not from Scrum, despite even how common velocity is used.

That said, we use general tickets for capturing time, but it's FOR the benefit of the team. We don't capture them so management can approve productivity; we capture them so management can help fix problems affecting productivity.

Ex: How much time spent attending external meetings, answering questions or investigating external service desk type support. We need to ensure they have time for the Scrum Events AND their work. Everything else is questionable.

Personally, I would side with the team member saying it's not fair. They know the value of the team is to be delivering functionality and is clearly committed to the goal of the Sprint, so everything else is appearing wasteful. The only Scrum meeting that could impede their progress is that precious 15min daily meeting. I would partner with this person and capitalize on the passion. As a Scrum Master, you are a servant-leader for the PO and the Dev team. They are the primary people. Everything presented externally should be built to support the goals of the Scrum Team, not the other way around.