Diversify story sizes, or else...

Disclaimer: all the statistics below are deliberately not exact, but rather based on the gut feelings (for multiple reasons). 

We seem to have come to an interesting situation: the distribution of our stories' sizes is very lopsided.

After breaking down all the "epics", we appear to end up with:

• Almost no 1 Story Points;
• Very few 2 and 3 SPs;
• Even fewer 5 SPs;
• The majority of stories being 8 SPs;
• Quite a significant number of 13 SPs (and that's the highest estimated effort before getting into the "epics" area).

So, bottom line: most of the stories in our backlogs (probably, 70-80%) seem to be 8-13 SPs, with the remainder being primarily 3 SP-ers.
And - just to eliminate this topic from the discussion - no, this phenomenon doesn't seem to be a product of so-called "story point inflation". 8 and 13 SP-ers are really that.

In my opinion, this is quite an unhealthy situation, with a multitude of drawbacks:

1. There may be not enough smaller stories in the backlog for the teams to "tightly pack" their Sprints.
   If a team's average velocity is 32, it can "digest" 2 13SP stories and be left with unutilized capacity of 6 SPs worth; or it can "bite off" 1 13 SP + 2 8 SPs, and have 3 SPs dangling. Of course, if there are 4 8 SP stories high in the backlog - excellent, but how often will that be the case?
   As a result, the effective velocity will drop below the level it could easily reach, if only there were enough small stories to pick.
2. The larger the story is, the more potential it bears for unpleasant "surprises" hidden in it.Of course, the teams make the best effort to analyze the stories and estimate them correctly in advance... But we all know that sometimes "hidden work" can be discovered only when the actual implementation starts.
   With smaller stories, there's just not enough space for "jack-in-the-box" to hide.
3. The larger the story is, the less accurate its estimation will be.
   In story estimations math, SPs don't exactly add up.
   What is considered to be "larger than 8, but smaller than 20" may end up being closer to 18 than to 13...
4. Having only large stories will result in all of them (hopefully) getting ready for testing towards the end of the Sprint.
   This means that:
   - Work in Progress is across the board. All the (few, large) stories are worked on in parallel.
   - Sequencing issues may arise between team members.
   - If the work on one of the stories gets blocked, there may be nothing on the board the team member(s) may switch to until the impediment is resolved.
   - If bugs are found, there may be not enough time to fix them before the Sprint ends; as a result, the story doesn't satisfy the Definition of Done, is not claimed, and has to be carried over to the next Sprint.
   - Team's QA doesn't have much to do in the first half of the Sprint.

The reasons for getting into this situation, most probably, lie in the subconscious perception that once the "epics" are broken down into something that is consumable - it's enough, the buck stops here. 

The solution, in my mind, is to try to convince the POs that the story sizes distribution should become heavily shifted towards the lower end: most of the stories will have to be in the 1-5 range, with some 8 SP-ers, and very few 13 SP stories (these would probably be spikes / investigations / prototypes).

This will require a concentrated effort by the POs, the Architects, and the teams themselves - to slightly change the mind set, to identify the stories that can be further broken down, and to keep doing that when estimating all the future backlogs.