Really excellent Steve a MUST watch for anyone wanting to use Flow Metrics. I find the hardest part is extracting the data in the first place. Some of the tools make it quite tricky!
No problem 👍 Well it depends on your software, for Jira watch this video (the principle is the same no matter what software you’re using) ua-cam.com/video/5Szv-w6n5NE/v-deo.html
I think that’s part of the beauty of flow metrics, Leadership and Stakeholders like them because they can understand them. They particularly like having a percentage probability of completion, it also makes conversations better I think.
Struggling to implement this with a customer that wants to know whether an 18 month new product development project will finish on time, but without a full product backlog for the entire project (which I'm resisting)
Haha yes classic. I normally have 3 reference sized projects that people are familiar with. Small, medium and large. Each size has the number of ‘stories’ it took. Together as a team we decide which one of these this new project is closet too and quote the 85th percentile using Monte Carlo Simulation. Then once the work starts constantly rerun Monte Carlo against the current backlog and update stakeholders each week. Try and explain to your stakeholder that attempting to create all the ’stories’ upfront is futile and most would be binned anyway. Use a language that they will understand - money - it will cost them more to do it this way plus most of it won’t be used. I’m not suggesting starting without any ‘stories’ on the table, run user/process story mapping and that would get you up and running very quickly. I put ‘stories’ in quotes as they could be PBI’s, features, tasks, work items, whatever your favourite flavour of poison is. One thing though, if you use Monte Carlo don’t mix and match, run it against ‘stories’ only don’t add in features or epics for example.
Steve, great video. However, you did not mention that those metrics are not meant for developers' performance evaluation and appraisal. What do you think?
Hi and thank you I really appreciate that 🙏👍 So, no, I do not believe these metrics should be used to evaluate developers performance and appraisal. They are team metrics to help delivery and to forge better conversations with leadership. I’ve worked at places that have used story points and velocity in that way, dark days. I’ll quote Goodharts Law “when a measure becomes a target, it ceases to be a good measure.”
Question. My cycle time is in excess of my sprint duration. Should we be working with the team to reduce the cycle time? I have heard that managing to a cycle time can be gamed and should not be a focus. Would love your thoughts on this.
Hey Doug and thanks for the question. Well the first thing to remember is that everything can be gamed. I believe the only way to avoid that is to build up trust and honesty, have an open and transparent environment where people can share thoughts and ideas without fear. If you have that kind of environment, and you should know from your retrospectives, then ‘gaming’ any particular practice shouldn’t happen. But yes your 85th percentile cycle time should be less than your sprint duration for obvious reasons. If the 85th percentile cycle time is above your sprint duration it’s unlikely you will ever meet any forecasts plus it suggests there are other anti patterns present such as too much wip, stories not well understood or too large. So I’d have a look at those things. If you follow this channel you’ll know I really like cycle time and Monte Carlo Simulation but don’t forget that none of these things matter if we’re not working closely with the customer making sure that true value is delivered.
Thanks!
You are awesome 😎 thank you so much 🙏👍
Cycle time and Monte Carlo yes yes yes!
Yes yes yes 😂
Great introduction to Flow Metrics!
Thanks 🙏😊 glad you enjoyed it.
Perfect thanks Steve, love the cycle time section!
Glad you enjoyed it! 🙏👍
Well explained, a must view for anyone looking at using flow metrics 👍
Thanks Graham I really appreciate that 🙏👍
Awesome just what I was looking for - many thanks 👍
Cool 😎
how to start was my biggest pain point so far, thanks for the step by step introduction!
You are very welcome glad you enjoyed it 🙏👍
Great video, just what I’ve been waiting for 👍
Glad you enjoyed it 🙏👍
This is absolutely perfect, will share it out 👍
Thank you, yes please do! 🙏👍
thanks for sharing more important info. I was missing your videos!
Thank you so much, that really means a lot to me 🙏😊 Yes, I’ve been away for a while but back on it now 👍
Really excellent Steve a MUST watch for anyone wanting to use Flow Metrics. I find the hardest part is extracting the data in the first place. Some of the tools make it quite tricky!
Thanks, I really appreciate that 🙏👍 Yes some of the tools are tricky but it’s well worth putting in the effort to extract the data.
Oh yes for sure 👍
👍
Fantastic!
Thank you 🙏👍
super video!!! Thanks Steve.
Thank you so much, glad you enjoyed it and thanks for the lovely comment 🙏👍
thanks Steve, really useful
You’re welcome glad you liked it 👍🙏
Another cracker mate 👍
Thanks Vince appreciate it 🙏👍
Thanks it's great 🎉
Thank you 🙏👍
excelente video
Muchas gracias 🙏 👍
Gracias!
You’re welcome, glad you enjoyed it 🙏👍
Hi Steve, where can I get the Montecarlo simulation in excellent. Looks great! 🎉
It’s in the description of this video
ua-cam.com/video/k22ZwODjgkE/v-deo.html
I agree with @user-kh5ku the cycle time section is very well explained. !!
Thanks 🙏 😊
Great videi 15 .07
Thank you that means a lot to me 🙏👍
Gracias for the subtitles in Spanish. Is there an straight forward way to obtain my data?
No problem 👍 Well it depends on your software, for Jira watch this video (the principle is the same no matter what software you’re using)
ua-cam.com/video/5Szv-w6n5NE/v-deo.html
buen video¡
Muchas gracias 🙏 👍
Are stakeholders open to this kind of metrics? Or have you encounter ant issues when using these methods?
I think that’s part of the beauty of flow metrics, Leadership and Stakeholders like them because they can understand them. They particularly like having a percentage probability of completion, it also makes conversations better I think.
Struggling to implement this with a customer that wants to know whether an 18 month new product development project will finish on time, but without a full product backlog for the entire project (which I'm resisting)
Haha yes classic. I normally have 3 reference sized projects that people are familiar with. Small, medium and large. Each size has the number of ‘stories’ it took. Together as a team we decide which one of these this new project is closet too and quote the 85th percentile using Monte Carlo Simulation. Then once the work starts constantly rerun Monte Carlo against the current backlog and update stakeholders each week. Try and explain to your stakeholder that attempting to create all the ’stories’ upfront is futile and most would be binned anyway. Use a language that they will understand - money - it will cost them more to do it this way plus most of it won’t be used. I’m not suggesting starting without any ‘stories’ on the table, run user/process story mapping and that would get you up and running very quickly. I put ‘stories’ in quotes as they could be PBI’s, features, tasks, work items, whatever your favourite flavour of poison is. One thing though, if you use Monte Carlo don’t mix and match, run it against ‘stories’ only don’t add in features or epics for example.
Steve, great video. However, you did not mention that those metrics are not meant for developers' performance evaluation and appraisal. What do you think?
Hi and thank you I really appreciate that 🙏👍 So, no, I do not believe these metrics should be used to evaluate developers performance and appraisal. They are team metrics to help delivery and to forge better conversations with leadership. I’ve worked at places that have used story points and velocity in that way, dark days. I’ll quote Goodharts Law “when a measure becomes a target, it ceases to be a good measure.”
would be nice to have this.... in jira
Yes I definitely agree on that 👍 Kanbanize has most of it built in…
@@TheAgileLeanGardener I know but you know....big companies...
👍
Question. My cycle time is in excess of my sprint duration. Should we be working with the team to reduce the cycle time? I have heard that managing to a cycle time can be gamed and should not be a focus. Would love your thoughts on this.
Hey Doug and thanks for the question. Well the first thing to remember is that everything can be gamed. I believe the only way to avoid that is to build up trust and honesty, have an open and transparent environment where people can share thoughts and ideas without fear. If you have that kind of environment, and you should know from your retrospectives, then ‘gaming’ any particular practice shouldn’t happen. But yes your 85th percentile cycle time should be less than your sprint duration for obvious reasons. If the 85th percentile cycle time is above your sprint duration it’s unlikely you will ever meet any forecasts plus it suggests there are other anti patterns present such as too much wip, stories not well understood or too large. So I’d have a look at those things. If you follow this channel you’ll know I really like cycle time and Monte Carlo Simulation but don’t forget that none of these things matter if we’re not working closely with the customer making sure that true value is delivered.