Estimation of similar functionalities in the same sprint

Last post 08:29 am June 7, 2013
by Ian Mitchell
1 reply
07:58 am June 7, 2013


How should the team estimate two stories with similar functionnalities in the same sprint. For example, let's says the first story talk about inserting one type of element in the DB from a web interface. The second, is to insert a second type of element in the very same DB.

For the first estimate, the team talks about it, a lot of uncertainty exist (they never did this) and they give, let's say 5 SP. For the second, the same uncertainty exist, but the team says: well, we should have tackle that in the first story, 3 SP should be ok.

Is it ok to estimate these stories like this?


08:29 am June 7, 2013


I'd say it's OK to estimate stories like that in the context of Sprint Planning, but it should be generally avoided in the context of reviewing (or grooming) the Product Backlog.

This is because in Sprint Planning, you will be arranging to deliver an increment of value. The stories that go into the Sprint Backlog should all contribute towards that increment and the corresponding Sprint Goal. Sprint Planning should identify any dependencies between them, as well as which should get done first, and good estimates will take into account those dependencies and that plan.

In contrast, when PBI's are sized in the Product Backlog, you cannot assume that they will be included into any particular Sprint. Therefore, I recommend that each story in the Product Backlog be estimated as though it was to be progressed in isolation. In practice there has to be some flexibility here. User Stories are often grouped in a Product Backlog and it is reasonable to do so in the context of Release Planning. In this case, estimates can and should take into account the expected ordering and dependencies.