Oh man, I love this. How many conversations have I gotten in about points for a particular story being correct and how we should repoint after a little change or after we were done
I think story points is one of those pfaf, trendy words that marketers and manager latch onto and integrate so deeply into their culture before ever taking the time to understand or develop business consunsus of its meaning.
Thank you for your content. If story points do not work, you mention to use cycle time, throughput, item aging, and WIP limits. Could you do a video doing a deeper dive to help teams with these types of forecasting? Thanks In advance! PS - I’m a new subscriber 😃
Hmmm - very interesting!! Following your episode of recommended reading (Amazon thanks you! 🤣), my copy of "When will it be done?" (along with a few other titles) has recently arrived - looks like this one will be next on my reading list 😊
What I will add to the conversation is that I still would suggest using Story Points, and just because they lead to unwanted behaviour in and organization - guess what? So can flow metrics. If an organization wants to bend Story Points into a toxic tool, so will they turn Cycle Time or Lead Time into such.
I personally have found no issues in using story points for long term forecasts or for guidance on how much to take in the sprint. Can you create a video on what you recommend instead of story points and how to implement that.
We detail a lot about flow based metrics in our Fixing Your Kanban playlist. That should be a good start for you. ruclips.net/p/PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6
Hi Ryan and Todd ... thanks for an amazing channel! We are having major problems of finishing sprints. We are already in sprint 10+ and have never finished all the items in a sprint. In fact we never get close to finishing the items in our sprints. We keep carrying over tasks from one sprint to the next. Do you have any advice on how to solve this? Are we overloading our sprint? Are we not estimating correctly? The team's morale is not great because we never finish a sprint. We are going to try and have a "Sprint 1" for our next sprint where we are going to not carry over any work but rather create new tickets and base the sprint load on our previous velocity (which is very low). Do you have any advice?
If this has be repeating for the last 10 sprints then I would first have your team taking on less work next sprint. Taking on a lot but not competing nor delivering will definitely hurt your team's confidence, trust and morale. There will be more benefits by taking on less and completing a full sprint than taking on a lot but not deliving at this stage for your team. Come up with a less ambitious sprint goal with your team in your next sprint planning.
Hi Mike! Is the team leaving planning with a Sprint Goal? My spidey senses tell me they are just trying to stay busy and complete a whole bunch of "stuff". It's completely okay to not finish all of the work planned in a Sprint -- that's what complexity often looks like where we find out about all the work that needs to be done when we're doing the work. I would emphasize the creation of a really solid, customer centric Sprint Goal. That, and of course, getting to done and maintaining quality.
I would say, mature teams should stop using story points. If used as intended (not as measurement of time, to compare teams etc) the action of jointly estimating effort using story points and the discussions and sharing of knowledge it can bring to a team is often far greater than what they did before "starting agile". With that said, as a team matures and their understanding of agile ways of working grows they should see the value in using other metrics like those found in EBM and Kanban since they bring meaningful information to the team. But introducing them to a team new to agile will probably fly over their head. Trying to understand "relative estimation" and why not estimate in time is hard enough for many when starting out :)
to be honest, I dislike the word sprint. Just the word allone stresses me, even if the workload tied to it is not stressfull. And if I am stressed I cannot think as good as when I am relaxed
Guys... aside from the content (I'll post a more detailed comment on this), a word to the wise: if you're going to repeatedly use a new word, and even recommend to your listeners that they "add it to their vocabulary", it'd help if you pronounce it correctly. Second syllable of "anachronism" rhymes with "knack", not "knock".
I'm trying to understand how to stop using story points. I come to the conclusion that a team really needs to understand the workflow and that workflow can't be "To Do, Doing, Done". Also, how do you get a team to agree on the typical "work item" and not let it look like a to-do task? I could see teams rack up items like "Make a call to customer" which would take minutes and size everything down to chunks down in minutes. Would that drive understanding and context like a "large" story would? An example would really help clarify to me what this would look like. I'm really interested in seeing how this works so I can help my teams see if this would work for them.
We detail a lot about flow based metrics in our Fixing Your Kanban playlist. That should be a good start for you. ruclips.net/p/PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6
I see ‘stop using story points’ I automatically ‘like’.
Flow metrics FTW.
Oh man, I love this. How many conversations have I gotten in about points for a particular story being correct and how we should repoint after a little change or after we were done
Todd, can you please share the link to the video on "Velocity" you reference at beginning of video? Thanks
I think story points is one of those pfaf, trendy words that marketers and manager latch onto and integrate so deeply into their culture before ever taking the time to understand or develop business consunsus of its meaning.
New student to project management. I got stuck on my last assignment. This content is so helpful. I used story points… I also like the Poker technique
“Welcome to sprint planing, the scrum ceremony where estimates are made up and the points don’t matter!”
Thank you for your content. If story points do not work, you mention to use cycle time, throughput, item aging, and WIP limits. Could you do a video doing a deeper dive to help teams with these types of forecasting? Thanks In advance!
PS - I’m a new subscriber 😃
Thanks for subscribing! This playlist might be a great place to start: ruclips.net/p/PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6.
So what’s interesting, the companies I have been working for are just catching up on agile and feel things like cycle time are a bridge from waterfall
The main point i took aways is "Use them for the main purpose they were created for"
Is cycle time appropriate for Sprints? With time boxing?
Cycle-time is appropriate for Sprints.
Hmmm - very interesting!! Following your episode of recommended reading (Amazon thanks you! 🤣), my copy of "When will it be done?" (along with a few other titles) has recently arrived - looks like this one will be next on my reading list 😊
Well, I'm interested in what you mean by this, as I see more pros than cons in using them in a Scrum Team's process.
What I will add to the conversation is that I still would suggest using Story Points, and just because they lead to unwanted behaviour in and organization - guess what? So can flow metrics. If an organization wants to bend Story Points into a toxic tool, so will they turn Cycle Time or Lead Time into such.
We find flow metrics to be closer to the work and more indicative of real obversations and progress. YMMV
I personally have found no issues in using story points for long term forecasts or for guidance on how much to take in the sprint. Can you create a video on what you recommend instead of story points and how to implement that.
We detail a lot about flow based metrics in our Fixing Your Kanban playlist. That should be a good start for you. ruclips.net/p/PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6
@@AgileforHumans Thanks. Will check that .
Hi Ryan and Todd ... thanks for an amazing channel!
We are having major problems of finishing sprints. We are already in sprint 10+ and have never finished all the items in a sprint. In fact we never get close to finishing the items in our sprints. We keep carrying over tasks from one sprint to the next.
Do you have any advice on how to solve this? Are we overloading our sprint? Are we not estimating correctly?
The team's morale is not great because we never finish a sprint. We are going to try and have a "Sprint 1" for our next sprint where we are going to not carry over any work but rather create new tickets and base the sprint load on our previous velocity (which is very low). Do you have any advice?
If this has be repeating for the last 10 sprints then I would first have your team taking on less work next sprint. Taking on a lot but not competing nor delivering will definitely hurt your team's confidence, trust and morale. There will be more benefits by taking on less and completing a full sprint than taking on a lot but not deliving at this stage for your team. Come up with a less ambitious sprint goal with your team in your next sprint planning.
Hi Mike! Is the team leaving planning with a Sprint Goal? My spidey senses tell me they are just trying to stay busy and complete a whole bunch of "stuff". It's completely okay to not finish all of the work planned in a Sprint -- that's what complexity often looks like where we find out about all the work that needs to be done when we're doing the work. I would emphasize the creation of a really solid, customer centric Sprint Goal. That, and of course, getting to done and maintaining quality.
Are you doing Backlog Refinement? A well understood PBI (a result of a successful BLR) is easier to get to done.
Can we give estimation/story point to the Bug?
Is Scrum Master should or must involve in estimation time?
Developers estimate work.
great
I would say, mature teams should stop using story points.
If used as intended (not as measurement of time, to compare teams etc) the action of jointly estimating effort using story points and the discussions and sharing of knowledge it can bring to a team is often far greater than what they did before "starting agile". With that said, as a team matures and their understanding of agile ways of working grows they should see the value in using other metrics like those found in EBM and Kanban since they bring meaningful information to the team. But introducing them to a team new to agile will probably fly over their head. Trying to understand "relative estimation" and why not estimate in time is hard enough for many when starting out :)
confused. flow metrics of what, exactly?
to be honest, I dislike the word sprint. Just the word allone stresses me, even if the workload tied to it is not stressfull. And if I am stressed I cannot think as good as when I am relaxed
Guys... aside from the content (I'll post a more detailed comment on this), a word to the wise: if you're going to repeatedly use a new word, and even recommend to your listeners that they "add it to their vocabulary", it'd help if you pronounce it correctly. Second syllable of "anachronism" rhymes with "knack", not "knock".
I'm trying to understand how to stop using story points. I come to the conclusion that a team really needs to understand the workflow and that workflow can't be "To Do, Doing, Done". Also, how do you get a team to agree on the typical "work item" and not let it look like a to-do task? I could see teams rack up items like "Make a call to customer" which would take minutes and size everything down to chunks down in minutes. Would that drive understanding and context like a "large" story would?
An example would really help clarify to me what this would look like. I'm really interested in seeing how this works so I can help my teams see if this would work for them.
We detail a lot about flow based metrics in our Fixing Your Kanban playlist. That should be a good start for you. ruclips.net/p/PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6