Tag: velocity

I’ve been accused of being a narcissist before. Not in those exact words, but I will never forget the conversation. I was 25 and a good friend of mine and I were talking. She finally said (in a rare pause of my banter), “Natalie, you always talk about you and never ask about me.” Wow, that one hit hard and I felt guilty and ashamed. I had never thought about it before. I wondered where my baby-boomer parents had gone wrong in raising me as a millennial snowflake (who was nothing but extraordinary) who didn’t know the true definition of meaningful discourse. Ever since then, I’ve put a concerted effort into making sure that I ask the other person I’m talking to questions about themselves. It’s a constant reminder in my awkward conversational brain – “ask them about their day, weekend, year…yeah—that’s perfect!” We often run into a narcissism problem in product development, too, and it can stem from fear and shame.

Talking to a team about carryover at a daily scrum meeting led me into a very uncomfortable confrontation with someone who already didn’t like me. Not sure why but I ascertained it had something to do with the unhealthy relationship between product and technology organizations and the fact that product was pushed by sales to make commitments on behalf of the teams that were essentially never met on time (more on that issue in a later post). So a contentious confrontation – read on…

This is a good follow on to the velocity and capacity discussion. If velocity is the amount of new feature work we can get done in a sprint and capacity is the amount of bandwidth we have in the sprint, other stuff fills in the delta between velocity and capacity. SO…do we estimate it?

We have a problem. Ok, I have a problem. I’m realizing velocity is often being used as a synonym for team capacity. In fact, I’ve done it, too. Don’t think that’s a problem? Well it impacts our forecasting, estimation, team health, and organizational expectations.

I’m going to start off by saying that I know Scrum and metrics don’t necessarily get along. But I will also acknowledge that it’s a necessary evil in most cases. And in a lot of cases it doesn’t have to be evil. Metrics are simply: a method of measuring something. In Scrum, we measure a lot of things. We measure the size of our work items, we measure the effort or time it takes to complete them. We measure our accuracy. All of this is in our quest to become predictable as a team and to improve (and we need to start with a baseline measurement to know if we’ve improved). But when others start taking notice of our metrics, that’s when things get tricky.