I'm the dev manager in my company. We're following what some people in the company like to call "scrum" but is in fact waterfall in scrum clothing - we are using some scrum terminology (backlog, sprints) but the PM, QA, and dev function as three separate entities in the delivery process.
This is roughly how our cycle looks:
Our development sprints are 5 weeks long, followed by QA sprints of equal length in which the full sprint content is tested.
We have a constant stream of "polishing" bugs (minor changes in UI layout, changing strings, etc.) as well as "major" bugs that are relatively small to fix (e.g. a missing null check that causes a user flow to fail). We allocate roughly half of the sprint for such bugs, customer cases, etc. and the other half for implementing user stories. The bugs work is estimated in a single "bugs bucket" work item per developer which is ~10 days long.
In the beginning of the sprint devs get a prioritized list of user stories with a reasonable amount of detail.
We have about 3-4 days of planning (that are part of the sprint) in which the user stories are assigned to developers and are broken down by those developers into tasks of no more than 3 days. Devs then commit to the user stories that we think can fit into the sprint.
The main difficulty, as I see it, is that we can't seem to properly estimate how long user stories will take. It is very common for user stories to slip out of the sprint because of an over-optimistic estimation. This consistently happens sprint after sprint. Now, while we do have some junior and new developers, I don't feel the problem is inexperience with the product because the same happens to our experienced developers. The result of this is that we increase our sprint length (it went up from 4 weeks to 5), but then of course the user stories got larger so this negated the effect.
My belief is that the user stories are too large. For example, it is common for user stories to be estimated at 20-25 man days (divided to two developers, e.g. GUI and backend) or even more (one recent user story ended up taking something like 70-80 man days, and its initial estimate was about half of this).
My feeling is that these user stories are too large and need to be broken down, but our PM strongly objects to this on the grounds that breaking down these user stories will result in stories that have no customer value (for example, in the 70-80 day user story I've mentioned, there was a lot of GUI work, a lot of backend work, a lot of DB work, etc. - but the user story would be completely unusable without any of these).
I was thinking that perhaps devs should force the US to be split to development milestones (rather than customer-facing milestones) and shrink our sprint accordingly, but I can't quite convince myself that this would help. I do feel that it is easier to estimate four 20-day items, since we have the data of the first item when estimating the second, but I am not sure it will give enough benefit.
I realize that fully analyzing our development process and finding what can be improved can take a significant amount of time and might be better-left for consultants rather than an online forum, but I feel that our problems should be fairly common...
Any input would be greatly appreciated.