nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Should We Track Velocity Per Person?

Parker Lovelace

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?)

Comments

Bob Ellis_w59u3a

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.

Simple Tyler

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

Parker Lovelace

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

Parker Lovelace

Great stuff, @Simple Tyler! 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