The Art of Story Writing in Agile

This post we explore story writing as an art, we refrain ourselves from re-inventing the wheel, instead we use the existing inventions, innovations and tools created by experts to arrange our thoughts to enable us to write good user stories. The intent of this post is only to gather relevant thoughts at one single place to help us write better stories.

Let’s understand when it is preferred to write user stories and when may be not to. Not everything needs to and will be from a user’s perspective during product development. There will be some stories which usually take the form of a task (technical story).
User Story v/s Technical Story
User Story v/s Technical Task

Artists tool-set for good user story

A minimum tool-set for story writing in agile includes writer’s inspiration, a structure for the story, conversation, INVEST model, splitting patterns, confirmation and alignment with the big picture.


Consider the case of “House of Cards”, a successful US TV series as an inspiration, after all what the production house did was not much different than what we are expected to do in agile.


Below is a sample template for user story (applicable for technical story/task as well). Note, the usage of “Task” here is in consideration to the tool JIRA where a Task is further split into sub-task.
Sample template for user story / technical story / task


Bring in the story for discussion with the team for exchange of thoughts, opinions, feelings, feedback, design decisions, any architecture concerns, performance concerns, security concerns etc. This is mostly verbal communication but most often will lead to creation of supplementary documents.

Apply INVEST or create SMART Task

Good user stories follow INVEST model i.e. they are Independent, Negotiable, Valuable, Estimable, Small and Testable. While tasks should be SMART i.e. Specific, Measurable, Achievable, Relevant and Time-boxed. Readers are encouraged to refer to Bill Wakes post on INVEST for more accurate details.

Apply Splitting Patterns

Richard Lawrence identified the following patterns that we can use to split a story. Each split of a parent story has to follow the IN-VEST model. Further Richard gives us a thumb rule to choose a pattern from the above list
  1. Choose the split that lets you de-prioritize or throw away a story.
  2. Choose the split that gives you more equally sized small stories.
These patterns are found to be comprehensive enough for splitting a story. It is recommended to read his post and the cheat sheet
Splitting Patterns


A good user story should contain a set of acceptance criteria based on which the customer will confirm that the story is “done”. The team will demonstrate the changes done using these acceptance criterion at the end of the iteration. For user stories, it is recommended to use Gherkin language for acceptance criteria’s. For task (or for user story w/o gherkin), ensure that the acceptance criteria’s written in plain English are specific and measurable.

Align with the Big Picture

Align your stories to achieve the big picture, this includes prioritization, story mapping and impact mapping activities. Especially when a story is split, prioritize the split (new story) and map it.

Identify Good user Stories

This section explores Logical Thinking Process to identify Good User Stories (Adzic, G) . Here we have 3 different system areas
  1. Zone of control, includes all those things in a system that we can change on our own.
  2. The sphere of influence includes activities that we can impact to some degree but can’t exercise full control over.
  3. The external environment includes the elements over which we have no influence.
    A good guideline is that the user need of a story (‘so That…’) should ideally be in the sphere of influence of the delivery team, and the deliverable (‘I want…’) should ideally be in their zone of control. Use this as a guideline, there may be valid exceptions and such exceptions are to be investigated.


Story writing is an immersive art, with practice it gets better and easier. Be the Leonardo da Vinci of your agile team to create your Mona Lisa(feature) from sketch to pastel, to final painting i.e. create thin vertical slices(stories) of your feature each time.
Sketch to pastel to Final Paint


  • Adzic, G. (n.d.). Zone of control vs Sphere of influence. Retrieved from
  • Lawrence, R. (n.d.). Patterns for Splitting User Stories. Retrieved from AGILEFORALL:
  • Wakes, B. (n.d.). INVEST in Good Stories, and SMART Tasks. Retrieved from
The opinions expressed herein are my own personal opinions and do not represent my employer’s view.