Regardless of the client I work with, the teams seem to initially struggle with understanding how big (or small) a User Story is, relative to Epics, Features, and Tasks.  It doesn't help when they first ask how big user stories are and my first response is "it depends". It's not uncommon to find team members asking if they can call smaller stories a minor or sub-story or a larger story a major story.  But then they get distracted by colors of index cards or some ancillary attribute.

The Distinction

Those who identify what the business wants (you may call him or her a Product Owner) take a stab at breaking down stuff to manageable chunks.  You can call those chucks an A/B-level requirement, epic, theme, feature, or spike. It doesn't matter what you call it.  But when the team estimates that stuff, it is still sometimes (more often than not) too big to fit into a sprint or iteration or just isn't ready to be worked.

We need to label [this] to set it appart as work that will be committed to next.  Either it will be scheduled in an upcoming sprint or it will be pulled to the next step on a Kanban.  To be clear, I'm not saying the team should start working on [this], merely because they think it is small enough to be completed within a predetermined cycle.  Until your team has sufficiently defined and mapped requirements, developed acceptance criteria, and removed all known blocking dependencies, it is still not a Qualified User Story.

Though I still use the term User Story as that placeholder for conversations, I believe the Qualified User Story more appropriately identifies a placeholder for conversations that meets a definition of ready and allows the team to commit to complete something within an estimated period of time.

Image Source: Pictofigo HT: Originally posted at LeadingAgile