I hope this video was helpful. 📖 If you need help facilitating a working agreements workshop, you can use this guide: [shop.scrummastered.com/product/workshop-team-agreements/](shop.scrummastered.com/product/workshop-team-agreements/) 📩 Subscribe to my newsletter to get updates on new stuff and special offers: scrummastered.com/free-downloads/
Hi Daria, happy new year! This is a super great and most useful video! Loved it! It clarifies a lot of things about this subject and I agree with you on all the points you've done! I wish that, sooner or later, I would be able to work side by side with an experienced SM like you or, a dream :D, with you!!!! It would be a great booster for my skills and competencies! Regards, Alessandro
Thanks Daria for wonderful video. How to find an accurate velocity when you have incomplete user story carried over to next sprint? (As most of the work done in the previous sprint)
You'll never get accurate velocity and that's not the point. But you may choose to re-estimate that carry-over based on the work left to give you a more realistic velocity.
Happy New Year. So should we re-estimate, what is left of an uncompleted work? How is that determined? The Team does this once in a while. I frown at it but I don't want them feeling demotivated or feeling bad that there's no value accepted for the work that has been done in the prior sprint.
@A Moore How do you determine what is left of a story? I don't think that's a great practice either. It becomes a trend for them. They would always feel that if a story is not completed, they can always carry it into the next Sprint and re-estimate what is left of it. I don't mind them re-estimating a story that's left untouched in a just concluded Sprint.
@A Moore I get your point, I discourage that because I don't want a Superstar on the Team. I think this creates silos on the Team and unnecessary roadblock in the event that this person is not available to continue the story, what will happen to the story?
I guess the other person's comments got deleted. You re-estimate the same way you estimate at the beginning just looking at the smaller amount of work left. Say you have a ticket that was originally estimated at 13 points. About half of the work is still left, so your estimate will be about 5 points. That's just a very generic example, of course.
@ScrumMastered how do you determine it's 5 SP. it is also so tough to break this kind of pattern if it becomes something encouraged on the Team. I know you did mention that we should try to discourage that and make stories smaller but while that is an ideal state, people love to quickly adapt to bad behaviors. I hope this makes sense?
@@labi2140 You determine it based on how much work is left, same as when you estimated it in the first place, except now the work needed to be done on this ticket is less. I don't understand how else I can explain it to make it clearer. What are we trying to discourage? I'm sorry, I'm lost
Considering the fact that the PO is responsible for the ordering of the product backlog. I would carry it to the next sprint as a PO with reestimation. I had this same issue as a dev, when the team dragged a huge feature through sprints. It was not pleasant.
If you reesimate based on the effort left and not taking the "busy work" in the estimation, does it mean that your velocity from the last sprint is not showing the real work or you won't see this busy work as part of the velocity since there is no increment created? Thank you! :)
not if you close the sprint and reestimate after. JIRA will save previous story points for previous Sprint and new estimations go to new one. not sure if I answered your question though 🤷🏻♂️
I hope this video was helpful.
📖 If you need help facilitating a working agreements workshop, you can use this guide:
[shop.scrummastered.com/product/workshop-team-agreements/](shop.scrummastered.com/product/workshop-team-agreements/)
📩 Subscribe to my newsletter to get updates on new stuff and special offers:
scrummastered.com/free-downloads/
Thank you 👍 Very valuable information and advice!
@vadymsalyuk8159 thanks for watching
Hi Daria, happy new year! This is a super great and most useful video! Loved it! It clarifies a lot of things about this subject and I agree with you on all the points you've done!
I wish that, sooner or later, I would be able to work side by side with an experienced SM like you or, a dream :D, with you!!!! It would be a great booster for my skills and competencies!
Regards, Alessandro
Thank you for the feedback. I hope that you get a chance to work with a great mentor soon!
Thanks Daria for wonderful video.
How to find an accurate velocity when you have incomplete user story carried over to next sprint? (As most of the work done in the previous sprint)
You'll never get accurate velocity and that's not the point. But you may choose to re-estimate that carry-over based on the work left to give you a more realistic velocity.
Happy New Year.
So should we re-estimate, what is left of an uncompleted work? How is that determined? The Team does this once in a while. I frown at it but I don't want them feeling demotivated or feeling bad that there's no value accepted for the work that has been done in the prior sprint.
@A Moore How do you determine what is left of a story? I don't think that's a great practice either. It becomes a trend for them. They would always feel that if a story is not completed, they can always carry it into the next Sprint and re-estimate what is left of it. I don't mind them re-estimating a story that's left untouched in a just concluded Sprint.
@A Moore I get your point, I discourage that because I don't want a Superstar on the Team. I think this creates silos on the Team and unnecessary roadblock in the event that this person is not available to continue the story, what will happen to the story?
I guess the other person's comments got deleted.
You re-estimate the same way you estimate at the beginning just looking at the smaller amount of work left.
Say you have a ticket that was originally estimated at 13 points. About half of the work is still left, so your estimate will be about 5 points. That's just a very generic example, of course.
@ScrumMastered how do you determine it's 5 SP. it is also so tough to break this kind of pattern if it becomes something encouraged on the Team. I know you did mention that we should try to discourage that and make stories smaller but while that is an ideal state, people love to quickly adapt to bad behaviors. I hope this makes sense?
@@labi2140 You determine it based on how much work is left, same as when you estimated it in the first place, except now the work needed to be done on this ticket is less. I don't understand how else I can explain it to make it clearer.
What are we trying to discourage? I'm sorry, I'm lost
Considering the fact that the PO is responsible for the ordering of the product backlog. I would carry it to the next sprint as a PO with reestimation. I had this same issue as a dev, when the team dragged a huge feature through sprints. It was not pleasant.
Yes, unfortunately, it's the most common approach to carry over - just drag it into the next sprint automatically.
If you reesimate based on the effort left and not taking the "busy work" in the estimation, does it mean that your velocity from the last sprint is not showing the real work or you won't see this busy work as part of the velocity since there is no increment created? Thank you! :)
not if you close the sprint and reestimate after. JIRA will save previous story points for previous Sprint and new estimations go to new one. not sure if I answered your question though 🤷🏻♂️