Defining The Qualified User Story

Defining The Qualified User Story

User StoryRegardless 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


5 Replies to “Defining The Qualified User Story”

  1. I have a team that consistently wants to know every detail about every story during Release planning (similar to waterfall & gathering all the requirements up front). What is the best way to break them of that habit? I explained to them that Scrum doesn’t expect all the details up front. Need some help

    1. Buford, do you have support from Management? If Management supports the process, you need them to communicate down to the teams the intent of what you are doing. You need their support. If not, you will continue to fight this battle. Sure, we need to understand the architectural roadmap and how our changes will align with that. Beyond that, I see a diminishing return on big upfront design. Things are going to change in the release. Things are going to be discovered during the release. The team is wasting time trying to know every detail about every story (beyond the ones in the next immediate sprint). Hope that helps.

  2. What about user stories, defining them so they are implementable. A story may be “As an Agricultural Analyst, I need to be able to import my survey results so I can analyze my data”. I foresee the stories below this that relates to what is the solution for the above stated story. Is that how you see it?

    1. Buford, look back at your feature. What problem are you trying to solve? Sounds like the customer (Agricultural Analyst) needs to analyze data. What is the acceptance criteria? 1. Data must come from survey 2. Data must be imported from csv file to db_foo 3. Data must be searchable in db_foo

      The acceptance criteria within a feature is what drives story creation. This way you create a minimal viable product. It also helps cut down on scope creep.
      When you base your user story on the acceptance criteria of the feature, you may then realize that the level of complexity is much greater then previously thought. You may rethink your implementation strategy or have to split that story into several so you can incrementally delivery on that original acceptance criteria, so that you can try and get a return on your investment earlier.

Leave a Reply

Your email address will not be published. Required fields are marked *