Epics

I was genuinely overjoyed to lead a team creating a commercial content management system. It sounded like an amazing UX and project management challenge. It turned out to be a nightmare right at the beginning when we started to create the user stories. The impending doom sort of nightmare, where you feel that failure is imminent, and you should escape the project as soon as you can. Almost none of the user stories fit into a sprint, and even worse, for at least six months the new CMS would not be releasable. Our map was full of epics.
After a brief period of panic, we started rethinking the approach. We had to forget the workflow-based approach and started breaking down the epics we had. One of the most stubborn offenders was this user story: I want to add new pages for my site and edit them later. Splitting this into creating a page and editing a page would serve no purpose because the same code would be responsible for creating new pages and editing the existing ones, and both were essential anyhow. The problem arose from the fact that the page could be a contact form, a picture gallery, an article, a blog post, a FAQ item, or many other things. Then, we realized that there is a group of elements that don't depend on the page type. Things such as the URL, the title, the meta description, and the status of the page (published, draft, deleted, and so on). We named them meta elements, although not all of them represent meta tags. This split created the following user story, passing all INVEST criteria: I want to create pages and edit their meta elements. This resulted in a backlog item that our senior Ruby on Rails developer could do in a day. It was testable and immediately usable in production because the early version had a text area below the meta elements, where you could put in any HTML code, which was then rendered below the heading. This text area was obviously replaced in the next iteration, but it was amazing for the Minimum Viable Solution.
The hidden benefit we discovered, when focusing on this user story, was that the user might not want to create the meta elements, so they should all have a default value. Moreover, the values should be linked, unless you broke that link. For example, you typed in the title, and the H1 element and the search engine friendly URL was generated from it:

We even had time to add meaningful labels, strong validation, and inline help. For example, you could see that you have only 65 characters in the title, as our recommendation (the green underscores). At that time, Google showed 69, so we underlined characters 66-69 with yellow and anything above 69 with red. It was possible to add a title of 255 characters, but our inline validation actively discouraged it. That alone could have been a user story, something like I want to create and edit the titles of my pages, while always knowing the character limits of it. Another story could have been I want all meta elements to have useful defaults and where possible generated from the title. However, that only leads to the story card hell. Our CMS could have had thousands of sticky notes. Instead, we stopped at the point where the user stories became small enough to be developed in half a sprint tops, while still big enough to solve a user's problem.