Thanks for your answer.

Just one thing that has been missunderstood in the explanation I made (probably my english it is not good enough).

The scrum master didn’t tell the team that a new story should be added. The thing is that in order to do the story (updating the third party controls), because a technical change in the new version of said suite of controls, after a few hours of starting do work with the story, the team found it was absolutly necessary and a must to build a new skin for our product.

Because completing that story was a lot of work and therefore other stories were need to be taken out from the sprint, that’s because scrummaster toldme that if I wanted them to continue with that story, others should be taken out from the sprint (but was in name of the team )

The fact was at the sprint review, the team did not agree to change the story points for that story.

Thanks,

Carlos.

The ScrumMaster should also not have been the one to demand that other stories be removed from the sprint. That should be up to the team.

And, yes I would have put a number larger than 2 or 3 on the story in this case. But I wouldn’t have considered it a re-estimate. What I’m reading above is a new change request that at the surface is similar to 6-7 past changes that were 2-3 points each. But there are other factors that make this one harder so I would estimate it higher since it will take longer. I’d view that as the first estimate given to this functionality not a re-estimate.

I’m the product owner of a company in Spain (Also I have the scrum master certificate )

First thing you need to know is that in our company, in general we decided no to change story points of the stories after they have been estimated during the sprint planning. We believe the important thing is the average and the option of doing it to all PBI we believe would be a waste.

But in the last sprint we had a situation that has been resolved in a way which I don’t think it was right.

Two days after sprint planning the scrum master comes to me and says that one of the stories (upgrading a third party components suite to the next version), required to build a new skin for our product (because this third company made an exceptional change in their components). So far, in the past, this story for updating the suite always has been a two or three storypoints (last 6 times we have done it more or less in that), but in this ocassion, really it has been more than 13 !

When situation is detected, Scrum master says that since this is a lot of work , if we continue with this story some other stories will have to be taken out from that sprint (finally about 12 story points were taken out). Original This story , at the beginning of the sprint, it was estimated in 3 storypoints.

The question:

-Given that this has been excepcional comparing to the stories in the past for updating this component, and

-Given that we had to take out stories from the sprint.

Don’t you think that this story should have been re-estimated to change the story points to what really was needed it or at least, change it to the number of storypoints that were taken out from the sprint ¿??

From my opinion, I clearly think that since the team and scrum master decided not to do it, velocity has been extremely altered.

Thanks and best regards !

I totally agree with you. And I’ve been doing exactly the same way as you describe and it is working pretty well.

“I don’t see why you think this might lead to an accuracy problem with the sprint burndown chart.”

Actually, I dont think it at all. Please, forget that ugly last sentence.

Thanks Again.

Pedro

Yes, every day each member is expected to update the estimates of any sprint backlog tasks for which they now know more. Generally, of course, estimates should go down but that won’t always happen.

I don’t see why you think this might lead to an accuracy problem with the sprint burndown chart. The sprint burndown chart should always show the effort remaining. That will happen if the team members update the estimates (in hours) as they learn more about what is left on a task.

If there any anomalies in the shape of that burndown chart, it may not be pretty but it will be informative. A wildly gyrating sprint burndown may indicate that the team doesn’t really understand the work, for example. Perhaps this anomalies in the burndown are what you mean by deviations. Seeing this is a good thing because it provides information to the team and their ScrumMaster.

–Mike

I’ve been doing almost the same Mike said he does.

I do Product Backlog estimates in story points, I than break the stories selected for the sprint backlog into smaller tasks. And after that, team members estimates, in hours, the length of each task.

But, during the sprint, i. e. everyday, the team members re-estimates the number of hours they think they will need to get the task they are working on done. And that reflects on a updated Burndown chart. It enhances the sprint visibility as it makes visible the estimates deviation and enable early decisions.

So, Mike, as you said your teams estimates the tasks on hours as well, do you re-estimates the remaining hours to complete the task too? If you don’t, do this deviation not affect the accuracy of your Burndown and can let to misinterpretation of it?

Thanks,

Pedro Reys

Yes, I think it’s OK to re-estimate. Practically, though, it happens pretty infrequently with the teams I’ve worked with over extended periods. They’ll re-estimate a story here or there every few sprints but re-estimating that little doesn’t significantly help or hurt the project. Any time we finish a story and realize we really blew it on the estimate, we should re-estimate that item. But we should also wonder: Are there other items in the product backlog that are similarly incorrect? There almost certainly are. So ask yourself what was unique about the re-estimated story that made you re-estimate and what other stories seemed similar before you worked on it and might therefore be estimated with the same error.

About Mike’s comment:

“Before I start this one I think it’s a 20 because the other one felt like a 20 after I did it.” That’s weaker than “Before I do either of these they seem the same size.”

Having taking Mike’s training on Agile Estimating & Planning, I am confused. To me, the main motivation about re-estimation was to use posteriori knowledge, and reflect your estimations continuosly to your customer when to deliver value using min/average/max velocity.

There even an example section in Mike’s training on Agile Estimating & Planning. There, a priory knowledge estimation of UI stories were low, then one of them proved to be difficult with a higher size value. Then, all related UI stories’ sizes we increased at Sprint Retro.

Could you tell me if/where I misinterpreted this thread / the training ?