“Never eat anything bigger than your head”, is a simple strategy for embracing complexity. User stories are naturally shaped and sized into concepts that people can get their minds around. This is one of the most effective “tricks” in agile development. This shaping and sizing is not always easy or obvious but it is often the key enabler for agile projects to excel.
This blog entry covers User Stories, one of the “natural forces” at work in Agile Development. I plan to cover how test driven development (TDD) acts to break down complexity at a more atomic level in a future post. When agile development is working well, it grinds down complexity like ocean waves smashing rocks into sand.
As an enthusiast and evangelist for agile development I am sometimes apologetic for dogmatic agile jargon that our community seems to force on people if they want to participate in even a basic discussion. An agile development “Story” is at least one concept that is worth inviting the discussion on important distinctions from Use Cases or Feature Specifications. A story may start out as a use case or come from a feature specification, but it goes through a valuable forging process the beats it into an agile story.
The reason I like the “story” term is that it emphasizes the verbal tradition. Product owners or business analysts need to be prepared to have a conversation. The story gets hammered into size and shape by dialog with developers. As P.O.s or B.A. gets more experienced they may get better at anticipating and preparing stories of an appropriate size, but this often presupposes a lot of design decisions. So, don’t overlook the value of continually refining stories through questions and interaction with the development team.
The “three C’s” of a story given below, comes from a simple reference on writing good user stories at:
The basic components of a User Story are sometimes dubbed as the three C's:
• Card - the written description of the story, serves as and identification, reminder, and also helps in planning.
• Conversation - this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.
• Confirmation - the acceptance test criteria that the user will utilize to confirm that the story is completed.
The Card becomes the physical token like a talking stick or kanban bin from lean. I know many teams are using online systems for tracking stories, so they don’t always produce a physical token. The trick with story cards is that it forces clarity in stating the story and constrains the amount of complexity. So, even if using a virtual story card with an online system, think of it like twitter, with some appropriate size limit on the description.
The Conversation is where the dirty details come out. People wonder about the role of business analysts or user experience people in agile. Their role is to be prepared to have a effective and productive conversation. This is where agile’s lightweight documentation approach wins because the verbal tradition forces clarity, and with a lively dialog the feature function concepts are tested for understanding by developers who will implement them
I call User Stories a good agile “trick” because they naturally mitigate risk. Estimation is simpler because each story has already been sized into a more predictable amount of effort. In a sense an estimate has already be made, that the story can be implemented in hours to days. This is one reason I favor shorter iterations over longer. I recommend 1-3 week iterations. When iterations grow into the 4-6 week range, the natural constraining force is not as strong and therefore risk of an incomplete or incorrect story implementation is greater.
Lean approaches further leverage this natural sizing because the story size is constrained to fit into a Kanban “bin”. This often means that a separate estimating step can be eliminated entirely because stories have already been sized to fall within some range of effort with acceptable statistical deviation.