The flow of the system of old was basically everyone commits to the master / main / trunk / default or whatever, and at some point something is built from a specific revision. This works well for small projects, but starts to have difficulty (as you noticed) when you start trying to go in different directions at the same time.
So, you branched for the 'sprint 1' for the role of 'bug fixes and stabilization of issues in sprint 1'. And now you've got sprint 2 that is coming up... and where should that branch be made?
Before going too far, lets delve a bit into philosophy of version control.
Each branch has one or more roles and a policy that is determined when it is branched.
Even if you don't think about it, it is the case. Even if you are working on the 'everyone submits to the master,' it is the case. I'm going to name these roles:
Well, I didn't name them. I
stole borrowed them from one of my variate documents on branching: Advanced SCM Branching Strategies
When you are doing the 'everything on master', master has all these roles. And thats ok.
The idea of a policy comes from Branching Patterns for Parallel Software Development and the policy branch. This suggests if the policy of the branch needs to change to facilitate work there should be a new branch. For example, if the policy on /trunk is "it must build successfully at all times" and in order to do some development, some work in progress check-ins are needed, that is a branch based on a change of policy.
Whenever one of those roles changes, or you need a subset of the roles, merge and or branch.
You've branched for 'sprint 1'. This has the role of development and packaging. Thats ok. But it isn't mainline. And that is where all branches should have as a parent or grand parent (or great grand parent) and where all code should eventually end up.
Branching from 'sprint 1' to 'sprint 2' means that the code for 'sprint 1' didn't make it back into the mainline. It should.
Ideally, you would branch for 'sprint 1' from mainline, work on it, and when work is complete, merge it back to the mainline. You can do that merge back to the mainline multiple times.
With 'sprint 2', it branches from the mainline, and work is done on it. As changes from 'sprint 1' go into the mainline, they get merged from the mainline into 'sprint 2'.
There's a better way of doing this
Back in 2010, there was a blog post about a model for git branching that tried to put some order into the branches. It was A successful Git branching model and has come to be known as 'git flow'
The 'master' branch is the one that git users tend to have as the mainline in many non-git flow cases. Its not here. Master is the tagged releases.
The mainline is the yellow one - develop. All branches eventually merge to develop.
Your sprint would be one or more feature branches (thats one way of looking at it) and once the features in it get merged to develop, a release branch is made from develop. That branch has the role of packaging - and the bug fixes are done on it and moved out to the master tagged releases and then back into develop - the mainline.
And wile thats all and good, you're using hg. So, here's hg flow.
It will impose a bit more structure on how you branch. Thats a good thing. You should be able to look at a branch and be able to figure out what goes in it, what doesn't go in it, where it is in the release cycle and work from there.
This helps in being able to identify exactly what role each branch has. You know where to go to build the latest release candidate. You know where to go to branch for a spike. You know how to get a hot fix into the product.
You could branch from the mainline for the sprint, branch from the sprint for each feature, merge to the sprint when the feature is done, and merge that back to the mainline. That works fine too. The sprint has the additional role of the accumulation in that case.
The key thing is to consider the different roles for each branch so that a developer knows what should and what should not go into any given branch. It will save you a lot of grief down the road by being able to reason about the structure of the branches.