Tracking velocity

Is there something else going on that is making them team want to be less transparent due to fear of something 'counting against their velocity'?

In my opinion, if the team chooses to track velocity then it should be a measure that helps the team plan and provide more predicable outcomes. In organizations who are unfamiliar with agile practices this metric can be weaponized or used as a way to compare team A to B which is an anti-pattern to watch out for. 

I don't understand this "count against their velocity" idea. Velocity is a measure of completed (done) work in a given Sprint. Adding work to the Sprint Backlog in the middle of the Sprint should not "count against" the team in any way. If they were to complete this added work, it would be included in their velocity measure. If they don't complete this work, then it is not included in their velocity measure.

Because they can't finish it by the end of the sprint, they want to remove it so it doesn't count against their velocity.Is this permitted?

@Kristen Bruckner, Why did they pull in work that they couldn't finish? What prompted it? What would be made transparent if the item stayed or didn't stay? Technically speaking, there is no harm in removing an item if it doesn't endanger or isn't relevant to the Sprint Goal. However, the mindset of "so it doesn't count against their velocity" does not help in any way. It's kinda obvious there is some underlying issues or lack of understanding regarding the concept of velocity.

My scrum team added a ticket half-way into the sprint and spent 8 hours on it. Because they can't finish it by the end of the sprint, they want to remove it so it doesn't count against their velocity. Is this permitted? My thought is that since they put time toward the ticket, it should stay. Any thoughts?

Which do you think your team should hold themselves accountable for?

• time spent
• velocity claimed
• work "Done"

Thanks everyone! The team is looking at velocity as a negative and not something used to track trends and help with goals moving forward. I've been working with them to explain the reason we're tracking, but they aren't getting it just yet. 

@Steve Vb At the time, one of the developers needed work, but then a few blockers came in. Also, another developer needed help on their ticket. I have one team member who tends to be very negative. I'm working on my 'therapy' skills! 

@Ian Mitchell Since we want to avoid rolling tickets over into the next sprint, I would say work 'Done.' Since I'm a brand new Scrum Master, if you think something different, any advice would be appreciated. 

When it comes to things like velocity, the perception can be very different when it's a metric the team understands and wants to track versus when it's mandated by a line manager or even a Scrum Master. 

It's also not uncommon for newer scrum teams to want to immediately pull work from the product backlog when their work is finished instead of looking for opportunities to help the rest of the team succeed. This is something that could be worth exploring if you're seeing a pattern. 

The team is looking at velocity as a negative and not something used to track trends and help with goals moving forward. I've been working with them to explain the reason we're tracking, but they aren't getting it just yet. 

Why are you tracking velocity?

Velocity is not a useful metric to track. It's highly unstable - it varies from team to team and even within a single team over a period of time. Velocity is usually pared with Story Points. Each team has their own definition of what "1 Story Point" means and the team can refine the definition over time, especially as the work and the team composition changes. Velocity is only useful for relatively short windows (a small handful of Sprints) and within a single team. Anything else is not a good or useful use of the metric.

At the time, one of the developers needed work, but then a few blockers came in. Also, another developer needed help on their ticket. I have one team member who tends to be very negative. I'm working on my 'therapy' skills! 

Why did only one of the developers need work?

Commitments are made at the team level. If one individual is finished with the work, the first reaction shouldn't be to bring in new work, but to help the team take on the existing work. Even before bringing on new work, I'd suggest minimizing technical debt (are you truly satisfied with test coverage on "done" work?) or cross-training through pairing or mobbing with other members of the Development Team. There are so many things that can be done to improve the quality of the Increment that the team is currently working on or improve the cross-functionality of the team that do not involve bringing new work into the Sprint.

Kristen,

Keep in mind that velocity is simply a tool to be used by the Development Team and Product Owner for planning purposes only.   It is simply a guide to help the Product Owner and the Dev Team assess what they may be able to complete in future sprint(s).

Any use of velocity outside of the purposes stated above is a misuse of the metric.

My observation is that the team does not have a great understanding of velocity and it’s purpose, this can be the case due to many factors ONLY known to you. So you might want to find out why they have a negative feeling about velocity tracking and you can do some agile games on velocity tracking etc to help improve their understanding of velocity.

My recommendation to you as New SM to the team is for you to let the team show you how they work. You can explain to them that you recommend they keep the ticket as it is the best practice to not add tickets halfway into the sprint of remove tickets halfway into the sprint.

As a new SM you can use this first sprint as an observation exercise to let your team show you how they work, the good the bad and the ugly way of doing things, have a one on one with PO and scrum team to get to know them better to help evaluate what the teams needs to improve on. This is an opportunity for you to find out about the coaching needs on agile practices.