Updating estimates during a Sprint

Hi Ian,

This is how I've interpreted the following part:

The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint"..."As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated.

- As new work is required = extra tasks for a specific User Story that is needed to complete the User Story.
- As work is performed or completed, the estimated remaining work is updated = when tasks are performed or completed, modify it to which you think it is correct.

Usually in my teams we attend to guestimate User Story relative from each other by using the Fibonacci numbers and subtasks by hours or sometimes nothing.

I’m my opinion it doesn’t really matter whether you use time, complexity, t-shirt sizing or even nothing, in the end it’s all about completing the stories that the team had forecasted. I’ve seen teams without any indication doing extremely well and teams using time, complexity etc. fail miserably.

Cheers, Chee-Hong

Wearing my Coach's hat I need to answer your questions by asking more questions (don't you just hate that?):
1. What will the team gain by updating story points in the middle of a sprint?
User Stories are measured in relatively abstract terms: points, t-shirt sizes, ideal team days, etc. Any "truth" in the measure is a reflection of the team's long-term performance (velocity) not day-to-day progress. In my experience, revising user story estimates after the sprint adds no value to the process and can introduce confusion when planning the next sprint. I'll agree with Chee-Hong that "as new work is required" refers to the tasks needed to realize User Stories. These tasks are measured in hours (a measure of "work"). The work estimates (hours remaining) are updated daily for/during the daily stand-up, so when new work (a new task) is added it is estimated. This is not a compromise: it's Scrum.

2. Do I understand correctly that the "new work" you are adding to a sprint reflects new user stories?
If that's the case I have only one comment: User Stories are measured in more abstract terms: points, t-shirt sizes, ideal team days, etc. Any "truth" in the measure is a reflection of the team's long-term performance (velocity) not day-to-day progress. In my experience, revising user story estimates after the sprint adds no value to the process and can introduce confusion when planning the next sprint. We don't add stories to a sprint in progress.

The cool thing about relative estimation is that it will autocorrect itself when you apply it within an iterative process.

A couple months ago I did I small research on relative estimations and it’s quite interesting to see what happens with initial estimations and how that affects the planning.
After my research I go into the Sprint Planning Meetings with a whole other intention :D

http://relativecomplexitytheory.blogspot.nl/2013/05/relative-complexity…

But who is responsible for updating the estimates during a sprint?

http://www.agiledistributed.com/

Ian, responding to your original question. Btw, thank you for all of your contributions to the forums -- I find your posts to be very informed and informative too.

Scrum and the Scrum Guide does not really speak directly "on point" on this subject, so you know what that means... ;-)

Frankly, I think sticking to reality is the best approach. Estimates are estimates and no one precisely knows how much effort does the actual implementations of most of stories need. So at the end of the day the team or individuals who underestimated a tricky story and have not delivered it ontime might be challenged by stackholders. So it makes perfect sense to be honest and say if something has been wrongly estimated even if whole the team disagree with you. The thing that does not add value is dishonesty, and/or being in bounds of what you guys have wrongly estimated and insisting on that wrong thing. I personally think the people who are working on some stories surely are the best people who know how many points it really is and the rest of people who disagree with them can give it a try and do those stories themselves if they think doing those stories is eady.

To grumble a bit I would say some people are just sitting beside the ring and saying "do this, do that". In reality these sort of people are nothing but noise. 

Stick to reality guys.

In my opinion and the way we work is, we have segregated the responsibilities across individuals where Business Analyst holds the responsibility of a Feature and stories. He also accounts for the task of updating the details, sizing, discussion, owning the stories, story elaborations sessions, etc. 

Updating the size of a story in the mid of an iteration is not advisable reason being it leads to the loss of track and Iteration chart looks distorted. In Agile we commit and learn from the mistakes that's why we tend to improve. So, what we follow is Do not update the sizes of the story between the iteration and let the team learn (even if it leads to spillover to the next iteration). But, we do have the practice of revisiting the sizing before the beginning of the iteration, during an Iteration planning session.  

Need for an iteration planning?

Ideally, Iteration planning should only be done if a Backlog grooming sessions have been conducted by the Business analyst. As in a backlog grooming session, we visit the backlog where there might be tickets or any new priority item lying. Thus the BA communicates the priority to the team and scrum master then replans the iteration. Another benefit of the Backlog grooming is that we provide a forum to the Team to ask questions on the stories that are planned for the upcoming iteration.  But, the fact is that SM also needs these sessions to plan their spillovers from the previous iteration.

hi,

my question is about re-estimating stories which is not finished in the past sprint. let me explain. for example we create a story with 8 story point. in the past sprint team done 4 task of it (for ex done 2 services and 2 widget) and for the next sprint 2 task of this story is remained in this case the story should be re-estimate or not?

@Neda Kashi, What does the Scrum guide have to say about incomplete Product Backlog Items? Consider if you'd want to discuss with your team why the work was not finished and whether you need to consider reducing the size of similar stories in the future?

Needa, considering that Story Points are intended for planning purposes only, how should you reflect the story point estimate of an incomplete item being planned for a future sprint?

Why not get the best of both worlds? If the team discovered new work that is required to meet the Sprint goal then it can be added to the Sprint backlog, estimated, and tagged in a way that shows it is a new discovery. You get the benefits of knowing your original estimate versus the actual as well as the new work. 

The team can choose to address this in the retrospective to determine if there's a pattern around emergent work...perhaps we keep missing a key dependency or don't fully understand technical implementation of the stories they've taken on.  

It may also help the team to try using the Cynefin framework. If we're discovering a lot of new work during the Sprint because our stories are falling into the Complex category then perhaps some research spikes could be conducted to mitigate any risks that emergent work can create. 

Good feedback! Thanks Tony!

Thanks Tony

"As work is performed or completed, the estimated remaining work is updated."

IMHO this could mean one of two things:

1.  The remaining work (which was already estimated) gets updated and detailed or broken down into tasks

2. Once work is completed, we monitor the progress by measuring the remaining work and updating the Burn-down chart.

I do not think it is a reference to updating the original estimate/re-estimating.

It puzzels me as well. My opinion on this:

As a team you would like to improve, also on your forecast. Story point estimates are meant to help you to give a forecast during Sprint planning. So do not update those estimates during your Sprint. It will affect your velocity in a way that you think you can pick up more Story points the next Sprint than you actually can as a team.

I would on the other hand let the team update the estimate on the tasks for a Story. These tasks embody the plan they have to complete Stories and reach the Sprint goal. If the estimates on tasks would not be updated, the plan would not be up to date for that Sprint and the team would not be able to monitor themselves in a proper way.

I'll share my experience (which doesn't use story points at all); but I imagine you could adapt the approach and still use it with story points. It'd just be more complex to do so, and (I suspect) less transparent, because it's incorporating weighted guesses, rather than hard data points.

----

A #noestimates approach can be to break items down down in a consistent way (e.g. the smallest feedback opportunity, or unit of perceived value, or small enough to be expected to fall within the team's expected cycle time).

Then, logically, as the Sprint Backlog is inspected and adapted, these items may be split further, as the Development Team learns more.

----

For the past 2 years, I've been tracking certain data on behalf of my Scrum Teams, to help them forecast at Sprint Planning.

We don't simply rely on velocity or throughput, because those figures are based on what is known at the end of each sprint, whereas we need to know the historic situation at previous Sprint Plannings.

What Tony Divel mentioned sounds like it's solving a similar problem.

I provide three data points:

1. Total number of forecast items at the start of each previous sprint
2. The total number of those forecast items that were resolved (either as "Done" or "Won't Do") within the sprint
3. The total number of not-forecast items that were resolved (either as "Done" or "Won't Do") within the sprint

#3 provides useful information about changes of plan within previous sprints. These items could be inspected to better understand why such emergent work came up. It could be anything from BAU that can't be anticipated, to a sign of poor refinement planning (which resulted in a heavily modified Sprint Backlog), to a sign of effective inspection and adaptation (as new insights were gained throughout the sprint).

But if we have an ongoing trend of an approximate number of emergent items in previous sprints, the team can usually anticipate a similar thing will happen in the current sprint, and that there will likely be a certain number of other resolved items, beyond whatever they include in the original forecast.

When adding specific items to the initial forecast for the new sprint, it shouldn't be based on the total number of resolved items from previous sprints, but instead, should be based on an empirical judgement of what can be anticipated during Sprint Planning. This figure would be based on data point #2.

The gap between #1 and #2 provides useful information to the team on their ability to achieve the items included in their original forecast. Whilst there is a large gap between these two numbers, it's a sign that their forecasts are over-optimistic. As the difference reduces or disappears, the Development Team may experiment with forecasting an increased number of items, also taking into account what it knows about the reasons for #3.