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.
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.
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.
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.
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
- 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.
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.