This isn't how story points are supposed to work.
They are a tool to estimate the backlog for unrefined stories and also help with sprint planning where the story points might be refined and typically subtasks are estimated in hours to help with burndown. It is valuable to estimate the backlog at a high level to get an estimate of when things longer term might be done. It is valuable at the sprint level to estimate in order to ensure the work is feasible in the timebox to meet the sprint goal. You should not roll up story points as this does not really help if you are equating the subtask work to team velocity and meeting the sprint goal.
In a team that goes through a defined process with say about 30% analysis 40% dev and 30% testing then why bother? Each story is the same, so use story points just at the story level and focus on getting things to done. Let's call one of these a 8
However along comes another 8 that has an entirely different makeup and you break it down using subtasks as 2. Analysis, 2 Database. 2 UX and 2 Test
Looks like a 8 in total but as a predictor of delivery (which is what story points are for) this looks like 8 for individual effort rolled up but there's a possible shortage of DBA skills. So if you are using subtask estimation for everything you might see this by profiling the skills against demand which might be a reason for subtask estimation but if you roll this up to stories you lose this important information which can help you understand whether the goal can be met.
So estimation at the story level makes sense if the work is similar and at the task level for velocity purposes makes sense if the work is variable. Rolling up story points doesn't seem to add much value for predictability in my view (other than management wanting reports) Also a 8 and a 5 don't make a 13 for story points, they are sizing buckets and not estimates.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.