The user story factory

In two recent blog posts, Waterfall with sprints and Demo, no review, we analyse typical anti-patterns we have observed when working with teams who try to transition to agile ways of working.

Core principles of agility

Often these teams will focus on the agile techniques and tools (daily stand-ups, burndown charts, user stories, etc.) but miss the opportunity to implement the core principles of agility; in this context, agility means business agility, i.e. the ability to deliver value to customers early and continuously, and iterate effectively to learn what makes a good value proposition for customers so that we can respond to market changes.

When teams fall back to working in a fixed time, fixed scope fashion, the Product Owner — perhaps the most strategic role in a proper agile set-up — inevitably sees his/her range of action significantly reduced. The first symptom is losing access to customers or stakeholders. For example, stakeholders might decide not to attend sprint reviews where most of the action goes into checking that the development team is making enough progress towards a fixed deadline.

Customer feedback

Ironically, customer feedback at this stage may even be seen as a noise rather than a signal, in that it requires the ability to change direction in an environment where we are essentially measuring percentage of completion towards a fixed backlog.

Without a feedback cycle, the focus of the Product Owner then becomes managing the delivery, to ensure that everyone is making as much progress as possible and is being fully utilised. Instead of measuring outcomes, we value utilisation as a measure of performance, since customer value is no longer a variable in our equation.

This creates the hype around metrics such as velocity, throughput, task completion time, etc. which often become measures of success for a so-called agile transformation iniatiative. Yes, very sad.

Anti-pattern

A very common anti-pattern we have observed in such scenarios is that the Product Owner becomes what we refer to as the user story factory. As soon as a Developer has completed a task, there is an artificial urgency to create the next task (the next “user story”) to keep him/her busy. Even if you are not an engineer yourself, you can easily imagine what the consequences of this behaviour are: lack of collaboration, no pairing, working in silos, no sharing of information, bloated estimates, etc. The list could go on forever. And none of this stuff is any good, unless your objective is to make a product no-one wants with low standards of quality.

Moreover, it greatly distorts the purpose of user story writing. A user story is meant to be an excuse for a conversation, an item in the backlog fostering the right collaboration between Product Owners and Teams who discuss the why, the what and the how in order to maximise value for the customer. When Product Owners turn into user story factories, this no longer happens and engineers focus on implementing whatever is written in that JIRA ticket because “analysing the work” is no longer their responsibility.

Soon, a team working like this will give up reviews and retrospectives. Why? Because continuous improvement is not their priority. So why waste an hour and a half running a retrospective when you could be sitting quietly at your desk working on a new task the Product Owner has just written for you? :-)