Suppose I have a user story of size 20 that can be split in other 2 user stories, making the original story an epic. Should the sum of these user stories add up to 20? What's the best practice in this case? If they don't add up that could mean in practical terms that the overall complexity of the project changed.
5
-
My personal thought is that the ticket needs to be split up first, and only after you have small tasks with no need for further subdivision are you ready to do any estimation.– IxrecCommented Jul 17, 2015 at 23:40
-
If you've taken a better look at the effort and decided a split is indicated, maybe the estimate of complexity has indeed changed.– Erik EidtCommented Jul 18, 2015 at 0:46
-
1"that could mean in practical terms that the overall complexity of the project changed.": The whole point of agile is to expect change, and be prepared to deal with it.– Bryan OakleyCommented Jul 18, 2015 at 16:21
-
@BryanOakley The thing we are dealing with right now is how much transparent we should be with the client regarding complexity change. Since at the start of the project we create a backlog with X number of sp that the client agrees on then a change of that number of story points would probably raise an alarm that would put us in a difficult situation, given that according to our velocity a finish date is set and changing the number of sp could affect that date. A proposed solution to this was having a sp buffer but I think that would create confusion of what sp actually are.– Cenobyte321Commented Jul 20, 2015 at 13:26
-
@Nab: the whole point of agile is that a complexity change should raise an alarm. You've learned your estimates are off. That is useful information for everyone. You now have a more accurate estimate of how much work is left, which will allow you to more accurately predict the end date, or allow you to know how much work you have to leave on the table in order to meet a pre-defined date.– Bryan OakleyCommented Jul 20, 2015 at 13:47
Add a comment
|
5 Answers
Not necessarily. The reason that higher possible story point estimates are usually farther apart (like in the Fibonacci sequence) is that estimation is less accurate, so it's not worth distinguishing between e.g. a 13 and a 14. But after analysis to split the stories, each part can be estimated with higher accuracy (that's one of the main advantages of smaller stories). So the total number can be different, because it should be more accurate.
-
1Agreed - but if you end up with a total which is wildly different from the original story, it's probably worth doing a sanity check. Most likely your original estimate was wrong, but :-) Commented Jul 18, 2015 at 10:29
No. The new numbers should not be compared to the old number. That's not thinking of story points the right way.
For example, if I were to split up an 8 point story into 1 point stories, I might get to 15 to 25 1 point stories. Is this because my team's definition of 1 point or 8 points is wrong? No, we defined 1 point to be a story which could be done in a few of hours, whereas we defined 8 points to be the largest size a single developer could push through in a two week sprint.
Other teams may end up defining story points differently, but idea is to use numbers that represent an honest estimate according to the team's rules and not lying in planning to make the maths work.
answered Jul 18, 2015 at 0:43
-
3I do think that story points are (originally) meant to be linear so that you can compare different stories of different size. Also the concept of velocity makes no sense otherwise.– hermanCommented Jul 18, 2015 at 10:03
-
@herman Velocity still works as the mid line of the bell curve. A story point is assigned based on a generic developer doing the work. Most stories in a sprint are 3 or 5 story points. The rare 8 point story is taken by the developer most familiar with the code (in an attempt to shave off some time). Simple 1 point stories are usually taken by developers least familiar with the code (in an attempt to widen the knowledge of the code base). Commented Jul 18, 2015 at 12:24
-
1But splitting that 8 point story into 25 single point stories would affect your velocity which isn't supposed to be the case.– hermanCommented Jul 18, 2015 at 15:08
-
1If you split one task into 25, it is highly doubtful that you'll complete all 25 in the time the original single task would take as there are often efficiencies at doing things all at once. For instance, it will probably take less time to add two fields to a form and then test than it would to add a field to a form, test, add another form to a field and test again.– user53141Commented Jul 18, 2015 at 20:08
-
1"Story points" should never be treated like time. They are a measure of task complexity, not a measure of the time a task will take.– user53141Commented Jul 21, 2015 at 0:48
The bigger the story, the less accurate the estimate will be. When you're talking about a 20 point story, that could easily reduce down to four 10 point stories, or two or three five point stories. That estimate of 20 is so large as to be almost as useless as a coin toss. All 20 really means is "it's too big"; the number itself means nothing.
The whole point of splitting stories into smaller stories is to be able to do a better job estimating. Since the estimates are better when you estimate multiple smaller stories vs one big story, that means they won't necessarily be mathematically the same.
Bottom line: don't worry about it. The estimates are merely a tool to help you plan. They don't have to add up, they don't have to remain static.
answered Jul 18, 2015 at 16:26
No. When you break up a task into subtasks there will be now be additional:
- time to context switch between each piece
- time to record each small story in the issue tracking system
- setup / teardown of configuration and test data
Also
- if you using the fibonnaci series (or basically anything other than every number), then breaking down a 13 point story (that was more like 11 but assigned 13 as the closest numeber might result in 3 stores, 3+5+3 = 11 points or a different 13 point story that is actually more like a 16 point story but assigned as a 13 point one 'cos 13 was closer to 16 than 21 was, might break down to 8+5+3 = 16(this is not even allowing dor startup , context switches, etc). So one 13 point story became 11 subpoints and another 13 point story became 16 subpoints.
Finally, this sort of focus on points at a small scale is frequently unproducitve and often gets used to try and estimate a points = man hours ratio.
I recommend using points to discuss relative sizing and generate discussion during grooming. Only use them retroactively over relatively long periods, i.e. months, when you need to forecast. Even them it doesn't work well as teams change and so does knowledge over time. Today's 11 pointer may be a 5 pointer with the staff and knowledge available then or vice versa.
answered Jul 18, 2015 at 11:05
Another factor: Even if your story points are the infallible word of god a change in the points as you split things up is likely due to roundoff.
Not all 1-point stories are exactly the same size. You break a 10-point story into 8 equal parts--you have 8 1-point stories but that's because you can't have a 1.25 point story.
