YDS: Capacity Sprint Planning vs Velocity Sprint Planning

[@hakaneriksson3660]

Thank you :)

[@stanislavpuhach5741]

And I tracked the drop in capacity after the planning to rise the discussion with the team why it’s happening and what are the consequences

[@tomaszniemiec]

🛬 I'm glad you guys are back. I was hungry without my daily dosage of scrum/agile challenge to solve for breakfast, :D And with this out of the way: of course I know the law. We call it the "student law" because if you allow students six months to write a piece, you will get it after six months - either because they will overdo it or start working on it just about when the time for delivery is near. I fall into the first category, as I tend to overdo stuff, which I try to mitigate using what I know about MVP and early feedback. 🛫 Pomodoro is actually a really cool idea for individuals. While when it comes to teams I would suggest flow metrics :)

[@marymiller1253]

Velocity was somewhat helpful in a previous project, but left a lot to be desired. I couldn't tell Developers had "issues" with capacity planning due to the changes happening in the organization, people going on leave, altering the Definition of Done, etc. For whatever reason, the Scrum Master would not adjust the amount of work pulled in based on past velocity. I probably wrote this elsewhere... It also created problems with internal stakeholders in that it created a perception that the team was always behind. Many internal stakeholders didn't really understand Scrum. I couldn't really use velocity as a way to forecast or give the sponsors a sense of how the work was progressing.

[@JordiEilers]

Great topic. Thanx again. I'll keep watching, and just ordered the book. BTW. something is wrong with Ryans sound. It is not in sync with the vid

[@AgileforHumans]

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 😊.

[@cfbredraider]

I use the Sprint Team Capacity Calculator Chrome Extension for all of my scrum teams during sprint planning. Works great!

[@AgileforHumans]

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

[@cfbredraider]

@@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.

[@AgileforHumans]

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

[@08yankeefan]

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

[@cfbredraider]

@@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.

[@neha-d1x]

What should be the better approach if not capacity or velocity planning. Please emphasize on this.

[@AgileforHumans]

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.

[@stanislavpuhach5741]

I use the term “capacity” to determine the availability of developers in hours. In this way I try to better understand the ratio between velocity as amount of work we deliver and capacity as the time when developers were at work let’s say

[@claudiajap427]

Hello guys, please so what if an organisation has to manage resources and have to spread resources across many projects. How then do they spread their resources without knowing estimating each individuals availability

[@AgileforHumans]

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

[@DocThorQ]

Guys, what is your view on Story Points, especially in light of Ron Jeffries's statement. The Father of the story points "regrets" that points are still in use, saying, "I think using them to predict "when we'll be done" is at best a weak idea;". I still use them. What are your thoughts about that? What else, if not, story points can be used? Ideal time again, #NoEstimates or what else?

[@AgileforHumans]

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.

[@sudakshinaghosh6342]

My team’s cycle time is not improving, especially the review and rework part. How can I improve that.

[@AgileforHumans]

Why does it need to improve?

[@tfadams]

"Velocity is not the point, delivering value is the point". Should be repeated often.

[@cfbredraider]

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.

[@tfadams]

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.

[@cfbredraider]

@@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.

[@tfadams]

@@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.

[@cfbredraider]

@@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.