Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum
Is it advisable to update story points after sprint is started?
Network:2101



We agree that scope of stories evolves during sprint duration and more clarity is established. Sometimes team find it more complex than expected. Is it advisable to update story points after sprint is started?
Sort By:
Network:2377



Yes, for a couple reasons. One, as you say, stories can be determined to be more complex than originally thought. It would expected to adjust the points as needed. Otherwise, an inaccurate depiction is portrayed. Two, for retrospective and future reference purposes, the story behind the story points will help with similar efforts later.

Conversely, if a story is deemed to be less complex, the points should be adjusted down as appropriate as well.

Even outside of agile, if requirements are analyzed and estimated, then more complexity is realized during the design stages, estimates are adjusted.

Things change, and true efforts are realized through further analysis, or once the developers are working. That is completely normal. It is expected that the changes, and they "why's" are captured to secure accuracy around the effort itself, and the documentation of the initiative.
...
1 reply by Sonali Malu
Jun 09, 2017 4:58 AM
Sonali Malu
...
Thank you Andrew for explaining this well...
Network:438



Although practically there are instances when the story points got updated in between the sprint..
Updating story points after start of sprint is not a recommended practice.
That signifies that the initial estimate was incorrect and inaccurate.
...
1 reply by Sonali Malu
Jun 09, 2017 4:59 AM
Sonali Malu
...
Thank you for your inputs...
Network:470



Story point estimation is a relative ranking. You select base stories for each point like Login screen is 3 SP, Search has 5 SP and reports has 8 SP. Now using these three base stories, you are estimating other stories - based on what is small and what is big, how hard it is? How much volume of work?
By getting answers to above questions, you visualize the size of user story which is equivalent to one of base story.



Note: Story Points are unitless. These points do not communicate about how many days day will take or how many hours they will take. Story points do not decay Thus, reestimation is only advised when there is an error in identifying the size of the base stories which are used in relative ranking. , if size is not estimated well you can re-estimate.


'For more details, please refer following video: https://www.youtube.com/watch?v=K5EKB7qviGI
...
1 reply by Sonali Malu
Jun 09, 2017 4:59 AM
Sonali Malu
...
Thank you for your inputs...
Network:1894



The point is: while it depends on the method you use to pay attention at the implicit or explicit change management process defined into the method, nothing must be updated during the sprint. If the scope changed because the stories changed then you have to update the estimation. But ones again, it will depend on the change management process.
...
1 reply by Sonali Malu
Jun 09, 2017 4:59 AM
Sonali Malu
...
Thank you for your inputs...
Network:877



It's not "advisable," but that doesnt mean there won't be circumstances where you need to. But, don't stop there.

Make sure you involve your Product Owner; changing your story points does not change your velocity. If, as Andrew mentioned, you reduce your story points, you may need to add another story to maintain your velocity. Conversely, you may need to decide which story won't get finished during the sprint if you increase your story points.

If this happens regularly, bring it up as something to figure out during your next retrospective. There may be something you're not doing when preparing certain types of stories that you need to start doing. You may need to update your definition of ready. Leverage the team to identify why this happens and what you can do about it.
...
1 reply by Sonali Malu
Jun 09, 2017 4:58 AM
Sonali Malu
...
Agreed Aaron!
Network:2101



Jun 08, 2017 1:17 PM
Replying to Aaron Porter
...
It's not "advisable," but that doesnt mean there won't be circumstances where you need to. But, don't stop there.

Make sure you involve your Product Owner; changing your story points does not change your velocity. If, as Andrew mentioned, you reduce your story points, you may need to add another story to maintain your velocity. Conversely, you may need to decide which story won't get finished during the sprint if you increase your story points.

If this happens regularly, bring it up as something to figure out during your next retrospective. There may be something you're not doing when preparing certain types of stories that you need to start doing. You may need to update your definition of ready. Leverage the team to identify why this happens and what you can do about it.
Agreed Aaron!
Network:2101



Jun 08, 2017 7:13 AM
Replying to Andrew Craig
...
Yes, for a couple reasons. One, as you say, stories can be determined to be more complex than originally thought. It would expected to adjust the points as needed. Otherwise, an inaccurate depiction is portrayed. Two, for retrospective and future reference purposes, the story behind the story points will help with similar efforts later.

Conversely, if a story is deemed to be less complex, the points should be adjusted down as appropriate as well.

Even outside of agile, if requirements are analyzed and estimated, then more complexity is realized during the design stages, estimates are adjusted.

Things change, and true efforts are realized through further analysis, or once the developers are working. That is completely normal. It is expected that the changes, and they "why's" are captured to secure accuracy around the effort itself, and the documentation of the initiative.
Thank you Andrew for explaining this well...
Network:2101



Jun 08, 2017 9:33 AM
Replying to Seema Sonkiya
...
Story point estimation is a relative ranking. You select base stories for each point like Login screen is 3 SP, Search has 5 SP and reports has 8 SP. Now using these three base stories, you are estimating other stories - based on what is small and what is big, how hard it is? How much volume of work?
By getting answers to above questions, you visualize the size of user story which is equivalent to one of base story.



Note: Story Points are unitless. These points do not communicate about how many days day will take or how many hours they will take. Story points do not decay Thus, reestimation is only advised when there is an error in identifying the size of the base stories which are used in relative ranking. , if size is not estimated well you can re-estimate.


'For more details, please refer following video: https://www.youtube.com/watch?v=K5EKB7qviGI
Thank you for your inputs...
Network:2101



Jun 08, 2017 11:21 AM
Replying to Sergio Luis Conte
...
The point is: while it depends on the method you use to pay attention at the implicit or explicit change management process defined into the method, nothing must be updated during the sprint. If the scope changed because the stories changed then you have to update the estimation. But ones again, it will depend on the change management process.
Thank you for your inputs...
Network:2101



Jun 08, 2017 7:21 AM
Replying to Ayan Kumar Roy
...
Although practically there are instances when the story points got updated in between the sprint..
Updating story points after start of sprint is not a recommended practice.
That signifies that the initial estimate was incorrect and inaccurate.
Thank you for your inputs...

Please login or join to reply

Content ID:
ADVERTISEMENTS

"There is no shame in not knowing; the shame lies in not finding out."

- Russian proverb

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events