Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,502
Community Members
 
Community Events
176
Community Groups

Should We Track Velocity Per Person?

My company operates in a Scrum fashion, using two-week sprints, holding ceremonies, etc. A new member of leadership in our Engineering department seems to think it would be a good idea to keep metrics showing each developer's "personal velocity" each sprint. 

On the surface, this sounds very "anti-Scrum" to me. I can't help but feel that breaking down our existing scrum team metrics into individual metrics will only push the members of our scrum teams to focus on their own commitments and accomplishments rather than those of their scrum team as a whole. 

I'd love to hear some feedback on this. Good idea? Bad idea? If we do it, how do you think it should be calculated? (i.e. total sprint velocity divided by number of team members?)

2 comments

Trust your intuition...  traditional managers have traditional intuition. Time to educate. Best measure of progress is working software that the team delivers. A cross functional, self organizing team figures out on their own the best way to manage the overall team's productivity to celebrate when working product is releasable.   GREAT last name... I assume you know the history of Ida.

Like Parker Lovelace likes this

Thanks for the quick response @Bob Ellis! I'd say you and I are very much in agreement here. I appreciate your input. 

And my last name is definitely a head-turner around my software friends ;) 

Hey Parker,

I would agree with you.  The focus should be more on what the team can accomplish during a sprint rather than an individual.

If you did measure per-user there would likely be more of focus on personal commitments.

I could also see some pressure being put on QA (not exactly sure how your process is broken down), but if everyone is trying to get sign off on their particular pieces it could become somewhat chaotic.

There may also be some situations where users have skewed results, either due to poor estimation or unforeseen complications.  If one user doesn't manage to complete anything there could be extra scrutiny and if one user has a good week they could get overloaded with work for the next cycle.  Having teams would balance that normally and ensure that a consistent amount of work is done every cycle.

Hope this helps,

Tyler

Like # people like this

Great stuff, @Tyler Brown! And I'm not just saying that because you and I agree on this issue :) These are some more good points I will bring up when this conversation inevitably comes around again in my office

Comment

Log in or Sign up to comment