Many agile teams can write user stories, some do it well, others do it well enough to get by and yet others fill in the min needed in Azure DevOps, Jira, Rally etc(your chosen app). A quick google/chatgpt search will tell you everything you need to know about writing user stories. LLMs can provide examples and details based on input context; infact i’ve utilized LLMs to good effect during activities for Product Owner/Manager class however there’s another side to user-stories that’s often misunderstood.

Having had my fair share of coaching and training agile teams on writing user stories, i’ve observed that teams do not place much importance on a user story meeting the 3C criteria or if it captures a value proposition or even if it addresses the user. In many instances, its simply a container for tasks that a team can accomplish within a sprint, small enough that they can size it, and descriptive such that it makes sense (at least) to the team so they can claim story points (at completion)

On a scale of 1 to 10 where the lowest is a one-word/line user-story that describe a task and 10 is a user-story that adheres to the INVEST mnemonic, demonstrates value to the user and helps align the team to deliver said value; you’d be hard-pressed to find an 8 or 9. Even with low quality user-stories; teams tend to meet their targets, stakeholders are provided a forecast, plans are created and work goes on.

What then might teams gain from getting better at writing user-stories ? the logical answer is that if they do, then its likely a better grasp of user value, such that each story represents unique value… for if it didnt, there would be no reason to work on it, and it would likely sink to the bottom of Team backlog. (team backlogs work on last-in-first-out principle)

This intense-focus on delivering value, while necessary… somehow makes user-stories the prima facie for all discussions relating to delivery of value because this is where all prior discussions crystalize into specific tasks that a team would (plan for and) complete to demonstrate creation of value.

Granted that some organizations understand the importance of establishing epics and features that capture larger requirements and progressively decompose epics to features to stories but the top-down process ensures that accountability is only applicable downstream and if a fully defined feature or epic is not available, it wont be considered necessary to write user-stories.

Some teams (and organizations) do benefit from regular coaching and training. Those are the ones supported by senior management, genuinely interested in making a change however others are left to learn/transform on their own. And these teams struggle with a larger structural dysfunction that places inordinate focus on trying to improve team’s ability and proficiency on writing user stories.

In many instances, the low hanging fruit is to run a story-writing workshop and there are a few reasons why this could be perceived to make the teams more “agile”.

First, it allows managers to retain their high pedestal in instructing teams. This ego-high is initially responsible for assuming that its the team that needs to improve on how to write good user-stories. If your manager is also identified as change agent, s/he wont be inclined to push for any change that shows them in a bad light or makes them look vulnerable.

Second, it allows managers to maintain status-quo – as long as the focus is not on identifying value streams, figuring out how to collaborate across departments and rolling up their sleeves to understand agile way of working, managers have an easy way out – agility is relegated as a team function.

Assuming no change to PMO intake process, newer projects would funnel through to agile teams where these are broken down to tasks and clubbed together to create user-stories. No wonder these user-stories resonate with tasks on a project plan and features equate to a sizable chunk of work (on the project plan). This in turn generates design stories, dev stories and test stories leading to waterfall-ing an iteration (known anti-pattern)

If you are on such a team or managing a team writing user-stories as a group of tasks, look for the existence and availability of artifacts up-stream such as – Vision, Roadmap, Epics, Features – are these missing ? Are Programs and Projects being renamed to Epics and Features ? if you’ve answered yes to either, its likely an indication of an anemic product management function.

These questions point to issues that a team likely has limited or no control over. When leadership is unwilling or unable to review value-streams, assess the appropriate use of Epics and Features to capture requirements, then teams really have no chance of writing good user-stories. Bad user-stories are as much an indication of team’s lack of proficiency as it is, of not embracing an agile way of working at the highest level. Treat these bad user-stories as a symptom of a larger problem and not just team incompetency.

If desired value isnt being described in Epics and Features, how then would you expect teams to go against the tide and describe it in user-stories. Agile works when everyone in the organization understand and embrace their role in the new way of working.

Next time you see a team struggling with bad user-stories, there’s probably more than meets the eye!

Share your thoughts, ask a question in the comment section below.