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.

Improve this question
9
  • 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, 2022 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, 2022 at 18:07
  • 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, 2022 at 19:35
  • 1
    @GlenSolsberry The question is tagged 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, 2022 at 21:08
  • 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, 2022 at 14:34

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.