Story Point Change Level

A user story is recommended to be as small as possible, but not to small that it would add complexity and overhead. 

Now, there is no one telling you what to do exactly, what would be most efficient for adding value here, taking transparancy, openness and the ability to inspect and adapt into account? And what does your definition of done say about this?

To answer your base question: you should estimate the work during backlog refinement. However, your overall process has a few points where its less than optimal and there are opportunities for improvement.

Ideally, you shouldn't be splitting Product Backlog Items in development. You should allocate sufficient time (approximately 10% of capacity, per the Scrum Guide - there are a number of threads here that talk about exactly what that means) to refining the Product Backlog. The output of this refinement activity should be Product Backlog items that are decomposed to a reasonable size, estimated, and well understood (among other things).

Something else to consider is that work should not have a "maximum effort" assigned. The effort or complexity is simply an estimate. Sometimes you're wrong and work takes more effort or has more complexity than you anticipated. This is something that can be discussed at a retrospective to determine what you can do to better estimate in the future.

I would recommend that you take a look at your overall workflow. Make sure that you are spending enough time to refine your Product Backlog before Sprint Planning so that way Sprint Planning can focus on decomposing the Product Backlog items into smaller work items that can be used to show progress throughout the Sprint and developing an overall plan for accomplishing the Sprint Goals.

I will put my question very simply. If team wrongly under estimated one particular  story but they completed that story by working extra late night so can we change the story point of the under estimated story at the end of sprint ?

If team wrongly under estimated one particular  story but they completed that story by working extra late night so can we change the story point of the under estimated story at the end of sprint ?

I would argue no.

First - I would question why the team worked late. Was this a team choice? Or was this dictated? One of the fundamental principles of Agile Software Development is that everyone involved in the work can maintain a sustainable pace. Working extra hours tends to not be sustainable. I would expect a conversation between the Development Team and the Product Owner to determine what the best course of action is to meet the Sprint Goal.

Second - the underestimation is a learning activity. It's something that can be discussed at the Sprint Retrospective. The team can determine why they underestimated the work and what they can do in the future to avoid underestimation.

I will put my question very simply. If team wrongly under estimated one particular  story but they completed that story by working extra late night so can we change the story point of the under estimated story at the end of sprint ?

If a completed story were to be re-estimated, wouldn't it show zero points remaining?

If team wrongly under estimated one particular  story but they completed that story by working extra late night so can we change the story point of the under estimated story at the end of sprint ?

Balaraman, you are looking at story points as a performance metric (which they aren't), and not as a planning metric (which they are).



Use story points in Sprint Planning to determine what the Development Team can comfortably forecast for completion in a given sprint.   Once the sprint begins, throw the points away.   The Dev Team has their Sprint Goal and PBI forecast (Sprint Backlog).

At the completion of the sprint, you may refer to the completed story points to provide another data point for your team's velocity, which is a tool the team can use in Sprint Planning to again determine what they can comfortably forecast for completion in the next sprint.

Any story point issue or less-than-ideal estimation of work should be discussed during the Scrum Team's Sprint Retrospective, with the goal to try and improve the validity and accuracy of future estimations.

Have you had situations where you over estimated a story?  Do you change the estimate for that?  

I'm going to say that if you change your estimate based on the work you have done, it is no longer an estimate.  Estimates are based on what you know and what think is a correct size. You use the estimate of the stories to estimate what you forecast you can do in a sprint.  If after the work is done, you feel that it was wrong you discuss it in the retrospective to understand why your estimate was not what you expected and how to see this situation occurring in the future.  The way I interpret your statements is that you are trying to make your estimates reflect actual work. 

I also questioning how the "8 point maximum" was determined?  I've worked with teams that have pulled 13 and 20 point stories into a sprint but they made concessions by lowering the number of stories that were also pulled in.  Sometimes stories can't be broken down or the act of doing so adds more complexity than is beneficial.