Aisha- God bless you. I am a new scrum master, our sprint closed today and I noticed we still have stories in progress I came on YT to look up what to do, and this video was the answer to my problem🙏🏾
Hello Aisha . Thanks for the video. 1. If a bug is raised, are we going to re-estimate that particular task in the next sprint or else they won't estimate at all. 2. After closing sprint 1 in Jira, we will start the sprint review and retrospective? Can you please explain this please? Also please make a video for what all the metrics to be collected and documented for discussion in sprint reviews or sharing the updates with the senior management team? Please make a video like this by considering an example in JIRA. Thank you.😊
Hello, it depends if your company estimate bugs, that particular task estimate do not change, but if you estimate bug in your company, then you should estimate it in the next sprint. The task will be blocked until the bug is fixed. 2. Yes, the last EOD of the sprint is when the sprint close (in my experience). But on that same day you will have sprint review and retro (but sometimes we can do sprint review 1 day before the sprint close due to time difference). 3. My sprint report video covers it all, watching my sprint review videos can also help. Thank you for watching 🙏🏾
I was confused at 14:30 on the carryover estimation; how do we say 5 storypoints are equivalent to 1 storypoint? I will rewatch and read more on estimations. Thank you Aisha.
Can you please clarify. I want to be sure I’m understanding: Around 12:48 you said do not reduce the estimate. And expect a higher velocity in the next sprint. Then at 23:23 you said for sure 100% you should reduce the estimate. It’s a little confusing. Can you please explain.
Sure I can. 12:48: do not reduce the estimate on Jira, but write the true remaining estimate to complete the task on a book (1), keep the same estimate on Jira, so that your team will get credit (5) for next sprint. Then the scenario for 23:23 is when the developer determine they over estimated the spill over for this current sprint, then for that same issue give it the true estimate by reducing the estimate next sprint. It two scenario. I hope this helps
@@AishaTech655 Estimation helps team with knowledge on the overall effort it would take for a task. Credit should not be the focus for the team but rather the value ROI being delivered at end of each sprint. JIRA also shows how long a task has been moving from sprint to sprint. Team can use the retrospection to discuss challenges faced that brought about the spill over.
Thanks for this video Aisha ! I have a problem . When reestimating spill over stories , my team often cannot reestimate them correctly and underestimated it. Which takes them longer time to finish and it impacts the sprint. How to stop it?
It not a good practice to re-estimate stories, and what you just described is a reason why. You will have to coach them not to re-estimate spill over stories, instead take on more stories if it only little work remaining from the spill over stories. It will take time but slowly you can get them there.
In overall PI we will be take 5 SP credits when it gets completee and committment would be twice i.e. 10 SP coz its has been spilled over to two SP how to handle this situation. In this case its only one story but tgere could be scenario when 2-3 qa stories are getting spilled over then committed is impacted. Pls advise
Are you saying you split the stories when it possible spill over and take partial credit ?? If so, it not a good practice, it a good practice to spill it over as is, team can take more work. Eventually the overall story point will even out with average velocity 🙏🏾🙏🏾.
No impact!! you can change times, but the most important your team need to know the new time each time you change it. It is best to have the same time for consistency and alignment.
Technically Jira will show the remaining story points but you believe the developer if he says it's going to take him just a day to complete then the developer can take on more tickets on the next sprint, this is very practical Aisha, thanks
Whatever task is remaining as at sprint end is carried over to the backlog for consideration and re-estimation for next sprint as agreed by team and PO. The remaining effort in story point is estimated.
Aisha- God bless you. I am a new scrum master, our sprint closed today and I noticed we still have stories in progress I came on YT to look up what to do, and this video was the answer to my problem🙏🏾
Very happy I am able to help 🙏🏾🙏🏾. Thank you for watching 🙏🏾🙏🏾
Thanks Aisha, this was very helpful.
Thank you for watching 🙏🏾
GOD BLESS YOU AISHA!!! I’m starting a starting role as a scrum master and I find theses video’s extremely resourceful
Amen, thank you 🙏🏾 🙏🏾🙏🏾
Hello Aisha . Thanks for the video.
1. If a bug is raised, are we going to re-estimate that particular task in the next sprint or else they won't estimate at all.
2. After closing sprint 1 in Jira, we will start the sprint review and retrospective? Can you please explain this please?
Also please make a video for what all the metrics to be collected and documented for discussion in sprint reviews or sharing the updates with the senior management team? Please make a video like this by considering an example in JIRA.
Thank you.😊
Hello, it depends if your company estimate bugs, that particular task estimate do not change, but if you estimate bug in your company, then you should estimate it in the next sprint. The task will be blocked until the bug is fixed.
2. Yes, the last EOD of the sprint is when the sprint close (in my experience). But on that same day you will have sprint review and retro (but sometimes we can do sprint review 1 day before the sprint close due to time difference).
3. My sprint report video covers it all, watching my sprint review videos can also help. Thank you for watching 🙏🏾
Well stated, find the root cause of the possible impediment before it creates growing technical debt. Such great advice!
Thank you 🙏🏾
Thanks for all the insight. How did you add story points to your tasks & bugs? Didn't know you could do that.
Thank you 🙏🏾, you can click the story and add the story point.
I was confused at 14:30 on the carryover estimation; how do we say 5 storypoints are equivalent to 1 storypoint? I will rewatch and read more on estimations. Thank you Aisha.
The 1 story point is the baseline, you are comparing other stories relative to that 1. Based on the complexity, effort, and how big it is.
@@AishaTech655 thanks for your response
good one
Thank you 🙏🏾 🙏🏾🙏🏾
Thank you.
Thank you for watching 🙏🏾
Can you please clarify. I want to be sure I’m understanding:
Around 12:48 you said do not reduce the estimate. And expect a higher velocity in the next sprint.
Then at 23:23 you said for sure 100% you should reduce the estimate.
It’s a little confusing. Can you please explain.
Sure I can.
12:48: do not reduce the estimate on Jira, but write the true remaining estimate to complete the task on a book (1), keep the same estimate on Jira, so that your team will get credit (5) for next sprint.
Then the scenario for 23:23 is when the developer determine they over estimated the spill over for this current sprint, then for that same issue give it the true estimate by reducing the estimate next sprint. It two scenario. I hope this helps
@@AishaTech655 Estimation helps team with knowledge on the overall effort it would take for a task. Credit should not be the focus for the team but rather the value ROI being delivered at end of each sprint. JIRA also shows how long a task has been moving from sprint to sprint. Team can use the retrospection to discuss challenges faced that brought about the spill over.
Thank you for your input 🙏🏾
Thanks for this video Aisha ! I have a problem . When reestimating spill over stories , my team often cannot reestimate them correctly and underestimated it. Which takes them longer time to finish and it impacts the sprint. How to stop it?
It not a good practice to re-estimate stories, and what you just described is a reason why. You will have to coach them not to re-estimate spill over stories, instead take on more stories if it only little work remaining from the spill over stories. It will take time but slowly you can get them there.
In overall PI we will be take 5 SP credits when it gets completee and committment would be twice i.e. 10 SP coz its has been spilled over to two SP how to handle this situation. In this case its only one story but tgere could be scenario when 2-3 qa stories are getting spilled over then committed is impacted. Pls advise
Are you saying you split the stories when it possible spill over and take partial credit ?? If so, it not a good practice, it a good practice to spill it over as is, team can take more work. Eventually the overall story point will even out with average velocity 🙏🏾🙏🏾.
Hi Aisha, what’s the impact of not closing the sprint the same time after each sprint?
No impact!! you can change times, but the most important your team need to know the new time each time you change it.
It is best to have the same time for consistency and alignment.
Technically Jira will show the remaining story points but you believe the developer if he says it's going to take him just a day to complete then the developer can take on more tickets on the next sprint, this is very practical Aisha, thanks
🙏🏾🙏🏾🙏🏾🙏🏾
Whatever task is remaining as at sprint end is carried over to the backlog for consideration and re-estimation for next sprint as agreed by team and PO. The remaining effort in story point is estimated.
Link to watch jira training:
ruclips.net/p/PLd3m1pI6BGHAfP8KNATIsM6DZJZvYdi6M