0

I've seen other questions on here about the fact that we shouldn't push for Team Velocity/Capacity to increase. That being said, we have a mandate from Leadership to try and make that happen.

We calculate team velocity at the beginning of every quarter based on the previous quarter's sprint metrics. We also track a "Say/Do" metric, which essentially is just a percentage of committed points vs completed points.

With that, does anyone have suggestions on how to use the Say/Do calculation to determine if we should increase/decrease capacity?

I'm thinking something along the lines of: avg(s1, s2, s3, s4, s5) * (5% + (avg(sd1, sd2, sd3, sd4, sd5)))

Which would see us automagically decrease velocity if we missed the committed metrics, and increase the velocity if we continually hit the metrics.

Glen Solsberry
  • 101
  • 1
  • 2
    "we have a mandate from Leadership to try and make that happen". Why? What problem are you trying to solve? And why do you think (or leadership thinks) increasing velocity is the solution? – Bogdan Nov 17 '22 at 18:06
  • I don't have the answers to that question, unfortunately, and I'm not really in a position within the company to push back on it. In the future I might be in a better place to do so, but for now, I'd like to try and figure out a solution. – Glen Solsberry Nov 17 '22 at 18:07
  • That's not a good place to be. Try to find someone that can push back, or at least tries to understand what the actual problem is. You have definitely been handed with an XY problem here, and you find yourself in the position to look for implementation option. Hopefully someone can respond with something else than "don't do it". – Bogdan Nov 17 '22 at 18:45
  • 1
    What is your role in the organization? Who developed this "say/do" metric and why is it considered to be useful or valid in any way? What is the actual problem, since saying that you want to increase velocity is the same as saying that you want to work faster? It seems like not only do you have an XY problem, but also insufficient data to make informed decisions. – Thomas Owens Nov 17 '22 at 19:35
  • I am a developer on one of a dozen teams. I'm trying to find a way to satisfy an ask. There is no one at this moment that is in a position to push back. I don't know the answers to most of your questions, as they're historical decisions before my time. – Glen Solsberry Nov 17 '22 at 20:37
  • 1
    @GlenSolsberry The question is tagged [tag:sprint] which implies Scrum, so where's your Scrum Master? Or agile coach? Or project/program manager? These are the kind of people who are in a position to push back. – Thomas Owens Nov 17 '22 at 21:08
  • I started to write an answer twice now and each time I couldn't really wrap my head around what you mean. Maybe we use words differently. You say "increase/decrease capacity". Do you mean hire more developers or fire some of the existing one's? Because that is what capacity is. – nvoigt Nov 18 '22 at 10:05
  • 1
    As an individual developer, one of the few things you can do is increase your estimates. Since story points don't mean anything other than relative complexity, theres nothing stopping you from increasing your estimates for everything. This will increase the velocity, but not do anything about the underlying problem leadership have. – user1937198 Nov 18 '22 at 14:34
  • Closely related: https://pm.stackexchange.com/q/17701/4271 – Todd A. Jacobs Dec 05 '22 at 02:29

1 Answers1

1

I assume the management is interested in increased capacity within the same team (i.e. delivering more with the same people). This can only happen if you have significant room for your team's flow improvement, -- assuming you are not talking about just inflating the estimates.
Combining/recalculating metrics won't help to deliver more or faster unless you have something to change regarding how quickly the work items are moving through your delivery pipeline. The change can be around decoupling, test automation, DevOps pipeline improvements, etc.
In a scaled environment, changing the size of the stories (smaller chunks) may also help to increase the whole flow through the system, i.e. smaller stories with fewer dependencies should allow delivering more through the same system.
Additionally, if you learn how to break stories down into equal small chunks then you can stop estimating and live with throughput as a key metric replacing velocity.

freedigit
  • 11
  • 4