What is a Qualified User Story?

Written by Derek Huether Thursday, 26 July 2012 11:55

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

 



3 Comments

  1. Mike Cottmeyer   |  Thursday, 26 July 2012 at 12:58 pm

    Derek… I agree. This is a huge impediment to getting predictable. If the team is making commitments to stuff they don’t understand, that is a big problem. It happens at every level of the organization…. strategy, program, portfolio, release… but often needs to get fixed where the rubber meets the road… at the user story and sprint level. Great post!

  2. Simple Cheat Sheet to Sprint Planning Meeting « Developers.BlogNotions - Thoughts from Industry Experts   |  Monday, 13 August 2012 at 1:20 am

    [...] purpose of the Sprint Planning Meeting is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on [...]

  3. Your Team Is New To Scrum | LeadingAgile   |  Tuesday, 11 December 2012 at 11:45 am

    [...] purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on [...]

Leave a Comment