Estimation

New learning and development can have an impact on future user stories that have been previously estimated as you've indicated in your example. I'd agree with you that it would be appropriate to re-estimate the user story and apply the learning from the previous Sprint. 

I've seen some teams that know Story 2 will become easier because Story 1 is creating a re-usable module and estimate it to be smaller during refinement. If the team misses this initially but it is learned through the implementation of Story 1...I don't see a problem with re-estimating. 

What are the potential consequences to not re-estimating? Perhaps the team under allocates themselves and needs to address bringing more work into the Sprint, focusing on technical debt, quality items, etc. 

If there are 2 user stories which are pretty similar, and by building the first story, the second story becomes much easier (because the approach taken on the first story can be used for the second), how does this work with story point estimates?

If story 1 is going into sprint 2 and story 2 is going into sprint 3, the estimates would have to be pretty similar, but after sprint 2, the second story, if taken in, would have a smaller estimate.

How is this handed in scrum?

I've run into this a lot. When it comes up, I often encourage the teams to estimate each Product Backlog Item independently. The Product Owner is responsible for ordering them and unless there's a hard dependency between them, there's no guarantee that they will be done in any order or even close in time to each other. The Product Owner can evaluate the benefit of each item and determine when it should be done based on the value that it will provide.

Surley you would have to reestimate stories which have already been estimated as new information is gathered, meaning story points do get stale.

As you refine, you should revisit. Completing any Product Backlog Item lets you learn more that gives you insight into any future Product Backlog Item. I think it's normal that an estimate can get stale. Until a Product Backlog Item is selected for a Sprint, the estimate isn't fixed.

If story 1 is going into sprint 2 and story 2 is going into sprint 3, the estimates would have to be pretty similar, but after sprint 2, the second story, if taken in, would have a smaller estimate.

How is this handed in scrum?

What you’ve done is to describe a plan or forecast of work. The estimates of each Product Backlog item should reflect that projection. In the case you describe, the second story can indeed be expected to have a lower estimate.

If they were estimated to be the same, the forecast would not be the best that the team could make, at this moment in time, given the information they have.

If story 1 is going into sprint 2 and story 2 is going into sprint 3, the estimates would have to be pretty similar, but after sprint 2, the second story, if taken in, would have a smaller estimate.

To me this indicates that the Development Team has identified that Story 1 must be done before Story 2.  Having encountered this a few times, I have discovered that my teams prefer to estimate Story 1 based on what they know now. Do the work on Story 1 in a Sprint. After completing or almost completing Story 1, they will then estimate Story 2 based on what they know at that time.  This way anything learned from doing Story 1 will be taken into account while estimating Story 2. 

If the situation is that there is no dependency but the stories are just similar, my teams have found that estimating them both at same time based on what is known is best. Then if/when they finish one they can always revisit the estimate on the other story before pulling it into a Sprint. 

Estimates can get stale.  They can also remain the same.  But always estimate based on what you know. If you learn something new about a story in the Product Backlog that has been estimated, discuss it to decide if it changes the estimate.  Also, don't try to estimate too far in advance. My teams usually will maintain about 2 Sprints worth of estimated stories at the top of the Product Backlog. That helps them if they need to pull in more work during a Sprint. If any story gets pulled low in the Product Backlog they will always revisit it when it comes back to the top portion of the list just to ensure that the original estimate is still valid.  I had one team that created an automated rule in Jira that said if an estimated story in the Product Backlog had been changed within the last 3 weeks, the estimate was removed entirely to ensure it was revisited. 

IMO, every Product Backlog item containing an estimate is tentative at best, based on the information and understanding of the Development Team at the point of estimation.   



All estimates can therefore be in flux, based on new understanding or knowledge gained, until the Sprint Planning event where the item is offered as part of the sprint.   At that time, the estimate is finalized in order to support the Dev Teams ability to ascertain whether they can deliver it based on their capacity and the item size.

Hey Dave,

Technically, Story Points aren't part of Scrum. So, there isn't a specific way to handle this in Scrum. As well, I don't believe there is a "right" way for how this handled. Keep it simple and what works to achieve the point of Scoring -- finding consistency with sustainable velocity to be predictable and enhance forecasting.

• What I would recommend is to simply score each User Story under the scenarios in which they can be worked on. So for example, score User Story 1 and User Story 2 as if they were to be worked on independently. Also, score them as if they were being worked on in the various scenarios that are possible and take note of those scores. Then, when the User Story is actually going to be worked on, apply the applicable scores based on the scenario route you are taking. 
• It may even make sense to merge the User Stories either actually or hypothetically, and score them together as a whole for a sense of Forecasting Total Project Scope.
• Going further -- as a goal, but not a law, aim to have User Stories written to be Independent of other User Stories. Obviously, this is an ideal and not always possible. This would avoid this debacle.

What is the problem we are trying to solve? (Is it a feeling of loss of transparency/accuracy?)

Just to remind everyone that Scrum is a Complex-Adaptive Approach and that we try to improve the quality of our decisions by postponing decision-making until the last responsible moment (i.e. JIT)? So, as a general rule of thumb, it's often useful to refine and estimate 2-3 Sprints' worth of Backlog Items as a 'buffer', but no more than this.

Notwithstanding that, long-lived Teams should get faster and that this improvement should be born out by an increase in their velocity...

In future, you could borrow a "Spike" from XP, and then, do some exploratory work in one Sprint, then use this information to estimate both Stories in the next?