All,
At the start of a new sprint our sprint backlog is filled with user stories that include story points based on a default value for a specific task or more accurate points based on insight and knowledge. If during the sprint a story is over or under estimated is it then advisable to change the among of story points according new insights or do one not change it, learn from it and do a better estimation in the next sprint.
Regards, Antoni
"If during the sprint a story is over or under estimated is it then advisable to change the among of story points according new insights or do one not change it, learn from it and do a better estimation in the next sprint." @Antoni Quintarelli
This all depends on the team and maturity of the team. If the team you are working with, keeps on changing the estimation on regular bases - then it is not good (Discuss in Retro and set protocols to encounter this for a smoother sprint)
effort estimate or guesstimates of a User Story depends on
(amount/complexity/risk of work)
If the team, changes it let say once in six month don't be a scrum police, I wouldn't sweat it if it was minor 1pt change but a major pt 13pt ->5pt is somewhat of a red-flag (can be something new for the team and will take time to adjust to this)
In both cases though bring it up in RETRO - "We had a story 1234, originally estimated at Xamount of Point, then it was re-estimated at x_amount of Point. What happened, Why did it happen??" So team can act accordingly in the future sprint.
Hello @Antoni Quintarelli
Your question is pretty common and has been discussed widely in the Agile community. Honestly, I am not a big fan of re-estimating the stories as that leads to loss of purpose of velocity over a period of sprints.
More detailed discussion on this topic here
https://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-the-question
and here
Adjusting Story Point estimates of issues during sprint.
https://medium.com/@mdalmijn/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have a Product Owner customer that keeps wanting to add additional User Stories near the end of the development cycle (2nd) week of a 3 week Sprint. It was never applied in the Original Sprint and they always say they cannot wait until the end of the next sprint. Suggestions or thoughts? Thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Do you know why the stories are coming in so late?? Is it a once in a while thing OR is this a pattern for every sprint???
Were this stories originally planned for next sprint and last minute being shoved in current sprint??
If it is high priority you can say I will bring it up to team as this is high priority, team will decide if they can get started on this - Team might drop other story/ies to work on new one, check with PO which low priority story you can substitute to bring in the one they want..
Tips:
Hold story session in your sprint where you estimate point for coming stories - get your Product owner involved in this to attend as team might have questions for them.
Groom backlogs as in terms of Importance (Business/Technical etc..) for sprint cycle before the end of current sprint so maybe by mid 3week you should be solid on for next sprint
Set up behind the curtain work, say your team is near the end of sprint cycle - team member can get a head start on next sprint work
Know your Team capacity/Velocity
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Do you know why the stories are coming in so late?? Is it a once in a while thing OR is this a pattern for every sprint???
Were this stories originally planned for next sprint and last minute being shoved in current sprint??
If it is high priority you can say I will bring it up to team as this is high priority, team will decide if they can get started on this - Team might drop other story/ies to work on new one, check with PO which low priority story you can substitute to bring in the one they want..
Tips:
Hold story session in your sprint where you estimate point for coming stories - get your Product owner involved in this to attend as team might have questions for them.
Groom backlogs as in terms of Importance (Business/Technical etc..) for sprint cycle before the end of current sprint so maybe by mid 3week you should be solid on for next sprint
Set up behind the curtain work, say your team is near the end of sprint cycle - team member can get a head start on next sprint work
Know your Team capacity/Velocity
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Gary_Weis
I wrote about this here saying:
the sprint backlog provides flexibility for the Development Team as they are only communicating a short-term forecast and stability for the Stakeholders as they know what they can expect to be available next.
Talk to your Product Owner about the importance of Trust when working in an agile team. Talk as a team about whether 3-week sprints are the right length. For more about sprint length check out this article (which has links to other articles).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.