Most of Agile test 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 the first response to get 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 apart 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 story board.
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.
