YDS: How Do You Increase the Velocity of a Scrum Team?

[@madzero0]

Is it me or is there just a little bit of emotion in Todd's voice? 😉

[@limitlesspotential3879]

I love when he said "can we get rid of the velocity completely?" Its totally true and I completely agree with it. Velocity is just a measure of number of story points delivered and does not show anything about what value is delivered and scrum always focuses on value delivered. The focus should shift from measuring outcomes and instead of output.

[@TheSebabaez]

Loved the video, when I saw the snippet came right in expecting Todd to go on a rant, wasn't disappointed 😂. Now seriously, couldn't agree more on the topic

[@tomaszgrygoruk5901]

One the best episodes , ever !! :) When I had seen the question I knew the the answer. From my point of view let's increase the understanding what needs to be done. This might be valuable and can increase effectiveness.

[@robertlegatie123]

Todd is 🔥🔥🔥. Love it. We are all Todd on this subject.

[@TechBroNina]

agreed!! velocity is such an arbitrary number subjectively tied to how a team measures ITSELF for personal growth, NOT for evm tracking metrics to juxtapose teams!

[@AgileforHumans]

*BETTER WAYS TO ESTIMATE, FORECAST, and MEASURE:* When Will It Be Done? By Daniel Vacanti - amzn.to/2XZyaMa Evidence Based Management (EBM) - www.scrum.org/resources/evidence-based-management

[@jasonlea]

Focusing on 'flow of work', optimising the system, reducing cycle time and monte carlo simulation are valuable areas to explore.

[@danielkemp9830]

Todd going off!

[@masterinuse]

There is even a Cost of Delay...WTH. Great episode guys, thank you.

[@TechBroNina]

i hope you folks open up with the fact that velocity isn’t everything :) and that it takes time to improve a team’s efficiency, and velocity is truly a subjective per-team basis arbitrary number!!

[@Rekettyelovag]

Well... blame the names. Velocity suggests speed. High speed of a (performance) car, how fast it can go from 0-60, how fast can you do your job? It's kinda logical to a person who doesn't do deep research. I said it multiple times that the one thing in Scrum that I don't like is the name of the iteration: Sprint (however, I understand y they chose that). The Wikipedia definition of a sprint is: "Sprinting is running over a short distance at the top-most speed of the body in a limited period of time. It is used in many sports that incorporate running, typically as a way of quickly reaching a target or goal, or avoiding or catching an opponent. " Needless to say, this implies speed and quickness, which is not what Scrum is about. But if you ask around, most management and devs say Scrum/Agile is about fast delivery. So don't be surprised when people ask this question and they try to make sense of it. Also it is really hard to talk these people off of this topic as they don't know how or can't do meaningful metrics. They want v=s/t. I wanted to write an article about this but never found enough time to do a proper research around it...so this is the quick and fast version. :D

[@g-ronnmendoza]

Velocity is not equal to Value! Output vs Outcome. People will just play by the numbers to make it look good. Never ending challenge in the world of Scrum

[@davidh6722]

Most metrics will be gamed if required. EBM is really difficult to collect and nearly impossible to game. Thanks for this vid.

[@osnyzinho]

Todd is nervous! Yeah!!!! That was funny!

[@tfadams]

In addition to what others said about Todd's emotion, which I heartily agree with, there are great references in here from both Ryan and Todd on books and classes. I seem to have the V word conversation at least every few weeks and I definitely sound like a broken record. But I remain optimistic that someone will listen and actually hear me 😃.

[@fernandoroldanrojas1435]

If it is not much to ask, can you please share an implementation of a better metric and explain it with real world scenarios? Unfortunately where I work velocity is all that matters.

[@MrAkkim]

Love this topic. Please create a few more segments on why this is no longer the best way or method of going about delivering tangible value.

[@neil1killick]

Your stakeholders never asked you for your velocity, but you gave it to them as a proxy for genuine progress. Now when genuine progress doesn't happen, they associate that with your velocity, so they want to know if you can increase it. Showing burn-up charts in the sprint review was the worst trick the devil ever played on Scrum teams! When you start addressing their REAL concerns - such as when will we be in market, when will we get the benefits - they will start caring about the way you present progress on those things, and they'll start asking things like "how can we increase the benefits?" or "how can we get benefits faster?". And, well, now the answers we can give are actually the things that Scrum/Agile/Lean UX approaches can help with, and we are all aligned! How wonderful would that be?

[@ankhayratv]

Great video. Can be used to show to people who think Velocity is useful. In fact, I'm going to share it with someone right now!

[@FlyyGuyVision]

yesss yess & yesss Velocity is what it is PERIOD end of story‼️

[@user-xk9oe8zx3w]

Love it. Thanks Todd and Ryans for the great explanation.

[@neil1killick]

You just increase your story point estimates - easy!

[@AgileforHumans]

😂

[@MarkBurville]

Absolutely passionate subject, love it, don't change Todd. Very funny 🤣 Stay Amazing 🌟 see you next year answering this one again :P

[@Daerdor]

Excellent vid, thx both!

[@CS-mq1gd]

Mr. Miller is gonna get a heart attack, lol! Probably pumped up enough to go lift some weights afterwards :). Mr. Miller's reaction is what I go through almost every day ever since we started implementing Scrum. Let me roleplay this out for you all Stakeholder(include Project sponsor/PO/PMO): What will it take to increase the Velocity of Scrum Team? Me: Increase Velocity AGAINST WHAT? Stakeholder: Well, I need my features to be delivered faster. Me: To achieve WHAT? Stakeholder: To finish backlog. Me: Backlog never ends! So again, for WHAT do you need Velocity to be increased? Stakeholder (frustrated): Well, I dont know. Just deliver everything! Me: There you go! We're lacking a VISION! Let's work on defining Value and see which items in the backlog are giving MOST VALUE for the least investment! Stakeholder: OK! Just 1 example of many. Boy, I'm pumped up now!

[@OffDaChainChico7]

If only it were that simple. My team has to migrate all integrations by X date. Otherwise, the company will have to upgrade its current platform and negotiate a price. It’s unlikely we’ll finish by the deadline.

[@TechBroNina]

i love your reaction LOL

[@marymiller1253]

I need to watch the video between Ryan Ripley and the person who advocates story points. Anyway, I have yet to see a good implementation of story points. One person asked me to story point a weekend upgrade. Unfortunately, the weekend upgrade required us to plan upgrade activities minute by minute time range of what we were doing so we could estimate how much work we could do before the maintenance window closed. I like one linkedIn posters advice to me regarding a frustration - ask what problem is this solving? If the organization had really insisted that I story point a weekend upgrade, I would have created a Work Item with a Story Point of 1.

[@detilium]

Let me just clarify a few things before you go all nuts Todd :) In some cases, "performance" can be an issue, but whether you look at velocity, performance metrics, or whatever it might be, it would make sense to actually figure out what's holding us back in regards of faster delivery of features. If there's absolutely no observations to be found in regards to "performance" from the Scrum Master's point of view; yes I agree, if you want to deliver faster, hire more people. BUT... To reference your other video, answering the question: "How should I facilitate my first Sprint Retrospective", perhaps one of the issues lies in refocusing on the Scrum Values, especially the "Focus" value. This is something I'm going through as we speak, as a Scrum Master. My team is not "focused" during the Sprint. They're messing around waaaay to much. Back to the referenced video; one of the things you mentioned was to actually bring the five Scrum Values to the retrospective, put these on a wall or whiteboard, and simply asking the team where they think they can improve. Maybe ask the team if it's okay to share your observations as a Scrum Master, and then bring the lack of "focus" to their attention, and ask them what they feel about their focus, and what we might be able to do to improve this. They might not have noticed it among all the daily work to be done. This will indirectly impact the velocity in the Sprints to come. Hope that makes sense, and that you won't strangle me in my sleep :D Great video as always guys, and what a good (though annoying) question :)

[@AgileforHumans]

You make some great points but I just don't believe velocity is every directly or indirectly impacted because of how it's been terribly misused by so many organizations. I do think you can influence Time to Market by removing the things that are in the Scrum Teams way.

[@AgileforHumans]

And we love a debate!!! No sleep strangling here😂😂😂

[@detilium]

@@AgileforHumans I see what you mean. Velocity is the incorrect metric to inspect for this, that's basically what you're saying correct? You could look at other metrics to determine the "performance" of the team (though I see no need for this, the lack of focus in my current team is more a simple observation), but the velocity is just the incorrect metric to inspect.

[@detilium]

@@AgileforHumans I can sleep well now, knowing that PST's won't strangle a PSM I 🤣

[@user-vk3xc8qs8n]

One could increase the velocity of Todd speaking by bringing up the topic of velocity. :). Other thing you guys could do is re-write SAFe so we can get rid of Story Points for features, etc. :). Okay, now I am just poking the bear. Seriously, the velocity metric really did leave many, in my previous organization, with how much work the Developers were NOT getting done. I couldn’t trust how accurate their estimates were because I didn’t know how they were evaluating what piece of work was 1 story point, and I didn’t know what it meant in terms of metrics I needed to bring to the sponsor. They were also struggling with creating Sprint Goals, and originally the CSP-SM stated Sprint Goals were not needed until I made a big stink about it (and later got called out for it). Velocity really meant nothing for me. On top of which the Devs worked 2 projects, and their velocity only showed their total velocity for both projects. That is the metrics for the 2 projects were not broken out so that each project could see metrics relevant to each project. The metrics were great for the Devs but meant nothing to anyone else. The reason why I love PSK so much is because PSK talks about the metrics I would have cared about and the sponsor would have cared about. The PSK metrics are way more understandable and transparent to those Stakeholders not familiar with Scrum. Story Points can enable Waterfall thinking. I am not sure if you tore apart the Mike Cohn post, but I would be curious.

[@Timaz88]

I thought calculating velocity is the BEST practice 😉

[@steve447]

Velocity is realized capacity.

[@rajadas6432]

On a lighter note, our uneducated leaders are biggest impediment to agile way of working. And I'll partially blame the certification bodies as well. The door is open for all to become CSM or PSM. PMP holds a gold standard for a reason. We could have done better by not making the scrum master roles as entry level job. We have diluted the scrum master role.

[@tomaszniemiec]

Good one. A good question. My default would be to go back to the team and set this as a challenge for the retrospective or build the meeting around this theme. On the other hand, if we are doing proper work with metrics and limiting WIP, having things like 'work item age' and flow diagrams giving us feedback on how we are doing AND we improve where we can constantly - this question shouldn't arise, right? So, the answer would be to build a second team? Looking forward to your view.

[@tomaszniemiec]

Loved the energy. I can sympathize with Todd here with my feelings on this, while I still have a feeling that it is a valid question from the management of an organization, as they would like to know what can be done to increase a team's performance, without any ill intentions behind it. They just would like to know how we can deliver more and often the question would be to create a new Scrum Team or something else. Maybe. Well, all I know that I prefer to understand what is behind the question: What do you mean by velocity? What is it about the current team's performance that is bothering you? Why is it important for you? Etc. Also, on the topic of Story Points: I know they have been used for the wrong sake, for wrong reasons, and they've been used with horrible results. While my take on them is similar to...alcohol: just because they are countless people doing it wrong and causing sometimes catastrophic results, does not make the thing bad, and I don't think we should ban it from the people who can use it well, and it brings them positivity, genuine positivity in many forms. I get fired up similar to when someone sees Jira and immediately claims "You use Jira? Jira is bad. Jira is no Agile. You Jira - No Agile" - WTF?! It's just a tool. It is no different from a wall of sticky notes. Just as slapping a kanban board on your office wall does not make you Kanban, so Jira is not implication if you are Agile or not. Blaming tools is bullshit and lazy.

[@sudakshinaghosh6342]

How to identify unnecessary meetings in a scrum team?

[@rajadas6432]

Question: How to educate leaders in agile way working without using word 'agile'?

[@AgileforHumans]

Describe the behaviors you expect to see from an organization that has embraced agile...

[@rmarkend]

@Todd, what about 1 story point = 8 hours? Are you saying that is not a real thing?? :P :P :P

[@AgileforHumans]

Please don't taunt Todd. Some of us have to work with him! 😂

[@hlipscomb18]

Velocity is a planning metric. How much work do we think we should pull in. If teams want to see how they are doing from an improvement perspective that is fine, but as soon as it becomes a productivity metric it will be weaponized and gamed.

[@AgileforHumans]

And it all too often becomes a weapon...

[@IanVellosa]

I really like this goto; video, with Cat Swetel: kzbin.info/www/bejne/mYiWqoBjgJeAZpo She breaks out a load of metrics, much like Dan Vacanti describes in his books. Well worth watching. Within our team I tried using some of these analysis topics, and found that tasks which took 3 days to complete had story point estimates from 1 to 5. Often tasks that were estimated as 1 or 2 points were taking longer than the average 5 point tasks. There appeared to be no consistency in the story point estimates. I like using story points as a way of discussing the complexity of a task. i.e. if most of the team are estimating 1 or 2 points and one person says 8 you have the basis for a conversation. Does that person know something the others don't? But after the story refinement/estimation just throw the numbers away. Keeping track of velocity (tasks/stories completed) in the team is ok as far as I am concerned. It's mainly when management get involved that it becomes a problem, where they want to see an improvement in speed. But if you remember back to your high school physics, speed != velocity. Going faster in the wrong direction does not help anyone, which is why I've heard on YDS a number of times we should be talking about the value delivered, not the features.