Thank you for ordering our book! And thank you for calling out that audio issue. We had it for two episodes but decided to release them anyway. After all, we are Agile and we are Human 😊.

Works great for who? Do you consider any other inputs during Sprint Planning?

@@AgileforHumans I'm a Scrum Master over 3 teams. I have used this during sprint planning the last few sprints and it helps give us a good idea of how many points we can take on each sprint.

The purpose of a Sprint isn't to achieve points 😊

If I said those words to my management team as a Scrum Master in our environment they may fire me…Our points are directly tied to financials (top 100 insurance company). They have up doing capacity based planning, by estimating our tasks but also expect us to deliver approx 8 pts per engineer per iteration and this drives what our velocity should be. Being unable to influence changes to these things has been a constant frustration

@@08yankeefan I don't understand this Agile Purity grift being pushed by all of these Agile groups, podcasts and influencers. It is totally disjointed from reality and what organizations need to be successful. The purpose of a sprint is to get work done in an iterative way but while also understanding how that work relates to getting larger initiatives accomplished. The only way to understand work predictability and how to resource for projects and allocate budgets is to measure them in a fuzzy way. It doesn't mean that things cant change but we have to have a benchmark to understand how and when goals will be accomplished. Full stop.

Flow Metrics: Cycle-time, Throughput, Item Aging, and WIP Limits. Check out Flow Metrics for Scrum Teams here: prokanban.org/wp-content/uploads/2022/08/flowmetricsforscrumteams.pdf It's free and awesome.

As we mentioned, if you are using velocity then it is one of several inputs into Sprint Planning to consider. It is not the ONLY input which is a huge mistake people make. The same goes for capacity. Velocity and/or capacity of one of many factors to consider during Sprint Planning. Other factors that should consider during Sprint Planning are: retrospective commitments, the Definition of Done, the Product Backlog, and/or the Product Goal. They all change the way we work. Now if you are asking what alternatives there are to velocity we highly advise that you read this book: www.amazon.com/When-Will-Done-Lean-Agile-Forecasting/dp/0986436372.

Why does it need to improve?

You mean people right? Not resources 😊. We did a video in the past on something similar: studio.kzfaq.infoQzPyTgvwiCw/edit?c=UCZYWqpkc-YzAndAt90arxTA

It is mostly up to the product manager/team to drive value work. Velocity absolutely matters as it relates to and is one way to measure whether or not that value is being delivered or not.

Velocity doesn't measure value at all. Team A has a velocity of 25, Team B has a velocity of 15. Did Team A deliver more value? We have no idea because velocity is just a measurement of the number of points the team "delivered". To a Stakeholder or end user there is no value in a higher velocity. The value is in the usefulness of the working software.

@@tfadams reread my comment please. Product is responsible for defining valuable work. Development is responsible for delivering said valuable work. Velocity tracks how fast and how long it will take to deliver the presumed valuable work. If the work is deemed not valuable that is not a development issue. That is a product issue.

@@cfbredraiderAgain, velocity only tracks how many points the team delivered as a lagging metric at the end of a Sprint. It does not measure value at all. Also, saying the lack of value delivered is a "product issue" is not agile at all. At the Sprint Review - Stakeholders: This was not what we asked for. Developers: But our velocity is 30 and last Sprint it was 25. We're getting faster. It's not our problem that you don't like what we delivered, talk to the Product Owner about that. Product Owner: I gave them work that was well defined... Even in the SAFe shops I have worked in, an Scrum Master that said that value is just a product issue, wouldn't be in that org for very long. The delivery of valuable software is the responsibility of the entire team, and the Product Owner is part of the team. It's not an us vs them thing.

@@tfadams If developers are delivering “well defined” work that meet product requirements and have been verified by product that the work completed meets said requirements (which is standard operating procedure) than it is 100% on product if other stakeholders don’t agree the work is valuable or what they asked for. Again, that is a product issue not a development issue. If requirements aren’t being met by developers then their velocity would go down because the work would not be considered done and roll over. Therefore, velocity tracks whether or not work that is defined by product is being delivered consistently. Whether that work is valuable or not is up to product to decide. Development is there to help execute on delivering valuable work, not define what is valuable or not. Not sure where this misnomer came from but it’s 1000% incorrect. Product isn’t expected to do development work, I am not sure why people think development should be expected to do products job. Yes, we are a team, but we have different job functions for a reason. Hand waving over that as “the responsibility of the entire team” doesn’t address where the issue lies.