Suppose the team is estimating a new item and want to say its equivalent to 20 story points because it’s similar to another item that has been estimated at 20 story points. That logic makes sense if the original item has not been re-estimated. If the old item was given an estimate of 10 before the fact and re-estimated to 20 after the fact then it is harder to know if the new item should get a 10 or a 20. With the re-estimation having occurred we’re in the position of saying “Before I start this one I think it’s a 20 because the other one felt like a 20 after I did it.

Let’s say we estimates a new item that is similar to a previous item which was originally estimated at 5 and ended up taking more. Even if we did not re-estimate this old item that, we still have the knowledge of how much more time it took. So that is going to influence the estimate of the new itme since it is similar to this old item. Are we supposed to pretend that we dont have this new after the fact knowledge and estimate as per the original estimate of the old item?

Ram

Considering the fact your original post is already 4 years old, I do wonder if you still think the same way.

My main problem with your original post is with your argument against mixing knowledge before the fact with knowledge after the fact.
I especially oppose to your following statements:
“When all estimates are given in before-the-fact numbers we can reason about them and compare them. Suppose the team is estimating a new item and want to say its equivalent to 20 story points because it’s similar to another item that has been estimated at 20 story points. That logic makes sense if the original item has not been re-estimated. If the old item was given an estimate of 10 before the fact and re-estimated to 20 after the fact then it is harder to know if the new item should get a 10 or a 20. With the re-estimation having occurred we’re in the position of saying “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.””

It seems to me that you’re suggesting that is better to keep making the same mistake in your estimation so you don’t have to adjust your statistics then to learn from your mistake and improve your estimate by using new information.

Of course, any estimation early on during a project or a sprint will be based on different knowledge then estimations later on. That is if you have learned anything in the meantime, which I truly hope so. To me, that is the most important aspect of any Scrum project and considering that inspection and adaptation are the 2 out of the 3 legs of Scrum, I feel Scrum agrees with me.

I don’t see why you can’t compare the one estimate with the other.
Re-estimating because new information arises seems pretty normal to me. You suggest it yourself when considering release planning and sprint planning.
A more important fact to consider in Agile estimating is the amount of effort that goes into estimating as fundamentally you can consider estimating as waste, eg. it doesn’t directly contribute to creating the final product.
In standard Scrum you might only do story estimation in a release planning session and more detailed story and task estimation in a sprint planning session. In the latter, you will have more information available and hence come to a more accurate estimate.
During a sprint even more information might come available, which may give rise to a new estimate. Not making this visible to everything via the burndown, feels to me as kicking against the transparency leg of Scrum.

I would advice to increase the amount of story points to be done in your burndown and re-adjust your ideal line to the end-date because you just found out that you have more work to do then expected.
If the team subsequently feels it can not make the sprint goal to which it has committed, it should consult with the product owner to drop something from the sprint backlog. That’s transparency.
Of cause, this may give rise to uncertainty about the value of the other estimates. But let’s not make certainty our primary goal.
Estimates have by definition a amount of uncertainty in it.
Within a sprint, the most important consideration is for the team to determine if they can still meet the sprint goal. If not, you will probably need to do some re-estimating to be able to discuss with the product owner what drops of the sprint backlog.
For future sprints and release planning your product owner has to decide if decreasing uncertainty is more important then building features. If the first applies then re-estimate, in the latter case then don’t.

Observing that reality is different from what you expected it to be and consequently adapting to this new reality is more important to me then trying to keep my velocity constant to improve my predictability.

In mine opinion, that’s going back to old-skool project management where we thought predictability was key and the way to achieve it was to adjust the reality to our plans instead of the other way around. I challenge anyone’s assumption that statistically estimates for IT-assignments will evenly be too high or too low. In my 20 years experience in IT-projects, the vast majority of people underestimated their work which means people in general tend to have systematic error in their estimation process.
Trusting statistics in keeping this systematic error under the carpet, may help you in keeping a certain level of predictability, but hinders you in analyzing your estimation errors and improving on then.

We can’t change the past but we can learn from it to improve the future.

When you find that often during a sprint, stories take much more effort then expected, you probably find that you can not make your sprint goals either. A thorough analysis of why this is happening and what you can do about it, then seems worthwhile. Maybe you’re using new technology which works better or worse then expected, you’re forgetting certain standard task like testing of documenting, your user stories tend to be not detailed enough or the teammembers are not communication properly with the product owner and users about the requirements. A closer look to which user stories tend to differ most form their original estimate might give a clue.
Whether you do this analysis mid-sprint or during the retrospective, depends on the urgency and impact of the matter.

When it only happens occasionally, it doesn’t really matter that much. The change in story points or velocity will probably not be outside your variance of your velocity anyway. But thinking along the three legs of Scum (transparency, inspection & adaptation), my tendency would be to re-estimate and adjust the burndown accordingly instead of saving it for the retrospective.

Good luck bring Scrum into your organization.

I am program manager for a development program and also the “change agent” for introducing Scrum. We have just started to use story points and come to some difficulties to understand how to do.

We have realized that a 20 point user story is too big for us to take into a single iteration. Just because we spend too much time on the planning meeting debating if we can fit into the iteration or not. The teams which had completed smaller stories do this with more accuracy than the team who had done bigger stories. Now to my question:

We use the methods to split a user story mentioned in your book “Agile estimating and planning”. (Very good help by the way). What do you recommend us to do with the story points after splitting a user story? Shall we use the numbers on the planning poker cards (for example 20 = 13+8 ) or can we use whatever numbers? For example User story “X” 20 story pints is split to user story “Y” with 10 points and user story “Z” with 10 points?

The software developers and verification/test people need to estimate collaboratively. I’ve had a few clients come up with 2-3 different estimates and add them together but they have each eventually abandoned that and come up with one number. It’s often a bit of a cop-out when I hear the arguments that go with the situation you’ve described. Initially, coming up with the joint estimate can be hard but over time the different specialists should learn enough about each other’s work that they can talk at the level needed to estimate—Your verification/test people don’t need to do the programming but they can contribute to discussions about whether something is bigger than something else. (And vice versa.)

The story points on a product backlog item (e.g., a user story) will typically go through acceptance testing but that really depends on what the team’s definition of done comprises. If true acceptance testing is done in the sprint (somewhat rare) then I’d expect the points to cover all the work up to and including that.

I am taking a traditionally waterfall project and over the past several months been trying to help them convert to an AGILE project. We have been hitting a roadblock with planning poker. When estimating we have both software developers and independent verification & test in the room. When applying points, because the level of knowledge is not the same across the board for both software and test, we get points based on differing assumptions. Even though we have a known base to estimate against that everyone agrees to, test has no insight into the level of effort for software and software has no insight into the level of effort for test. My questions are as follows:

1. How would you handle this in testing? Would only get knowledgeable software people and estimate based on development effort?
2. Would you consider having test only story point test time and aggregate them together with developer time?
3. My assumption has always been that story pointing includes the level of effort up through acceptance testing, is this correct?

Thanks for your help, not sure you remember me but I took 3 of your classes in San Jose, Oct 2008.

Thanks for any help,

Ralph

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.