Agile "user story" for a user-less project

Question

Disclaimer: I'm a total agile newbee.

As a project manager for a pilot agile project, I am trying to create a rough sketch of my project using agile methodologies, but somehow I am not sure how to do define each Story in the Epic-Story-Task hierarchy, especially given the "user-story" approach:

As a [user], I'd like to be able to [do that], so that I could [get that].

The problem is, there are no users that I can identify in my project. My project is defined as a communication extension of an existing project, in order to integrate it with a third-party system. A (say) 2-month job which I'd like to divide into (say) 4 or 5 sprints.

• We need to modify the hardware a bit, then test it at customer's site to see if it will suffice.
• Then get back to implementing some basic protocols, then test it at customer's site.
• Implement a bit, do a small release and test it.

Seems fit for small agile sprints.

But I am unsure how to write the Story-level tasks. I am pretty sure that either I got this whole "user" part too strictly, or that I can actually identify users for my stories. I could simply write "Test different communication options" as a story, but it surely violates the INVEST mnemonic.

What am I doing wrong?

Answer 1

TL;DR

Without knowing the specifics of your Product Backlog, a concrete answer isn't possible. However, some general guidance on crafting effective user stories may help.

The user in user stories need not be an actual end-user. Rather, it is a viewpoint character that provides context for development and validation of a feature. If you can't identify a person or role that would find value in a given feature, then you may want to revise your backlog so that it represents features rather than tasks, or decompose your stories further until a value consumer is discovered.

Viewpoints in User Stories

A user in a user story can be any actor that would derive value from the feature. Some possible users for your scenario might be:

• End-users of the communication extension.
• A specific role staffed at the customer site.
• An administrator or operator of the communication system.
• A network engineer supporting the infrastructure that your product relies on.

Identifying this user provides context, as implementation details are not part of a user story. The viewpoint helps the developers craft a solution from a feature-consumer's point of view, and often highlights the acceptance testing criteria necessary to ensure the feature is designed and built properly.

In cases where an actual person is defined as the user, then the story can also act as a conversation placeholder for starting a dialog with the person about the implementation of the feature. For example, if Joe the Administrator is the defined user, then the development team can work directly with Joe to clarify details or flush out issues encountered during the sprint.

Identify Value Consumers Through Feature Decomposition

Stories without a viewpoint are often a project smell. It may indicate:

• A plan-driven (rather than feature-driven) Product Backlog.
• "Stories" that are specifications rather than user stories in the agile sense.
• Featuritis that violates the YAGNI principle.
• Themes or epics that haven't been decomposed well enough to identify who will receive value from the feature.
• A story, epic, or theme that has been added to the Product Backlog without value-based prioritization by the Product Owner.

There are certainly other reasons why your stories may lack a user-centric viewpoint, but the list above is a useful starting point for introspecting your backlog grooming process.

In many cases, restructuring your Product Backlog to contain features rather than tasks is a great first step. Once you've done that, you should decompose the features until each feature has some quantifiable value and identified the likely consumer of that value. This process not only helps you write better user stories, but will also help the Product owner to properly prioritize stories within the Product Backlog.

Answer 2

I have been in a similar situation before.

We were working on a integration project where the features/requirements were not coming from users. In fact, a criterion for success was that the users didn't notice we had extending their application for integration with other apps.

I was asked to plan this as an Agile project, so I did. But now I regret it.

It ended up confusing everybody. People kept trying to talk about requirements from a user's perspective, they kept trying to manually test from a user's perspective, and they constantly questioned the business value of stories like "As a Solutions Architect, I want Entity X's CRUD events to be recorded in a Message Queue, so that EventPublisher can publish them asynchronously".

Agile as we had done it before wasn't a good fit.

Implementing the work iteratively was OK, because we found out that the spec changed frequently (though this might not be your case). But other than that, a Waterfall approach would have been much nicer.

So, in short. Maybe make use of Agile tools, but plan this as a Waterfall project.

Answer 3

A user story is not about a User, it's about an Actor which could be somebody who performs an action like:

As a Visitor I want to be able to do thing so I can get stuff.

Before you write the user story, you need to define your Actors, who are responsible for an action.

In my perspective an Actor can be a visitor, administrator, or even a system task.

User as an Actor is too broad of a term to be used in a user story.

Answer 4

I know this is a necro thread but just in case anyone (like me) stumbles across it. The issue here is not how we describe the story, but how we understand and analyze the requirement, in other words the business analysis activity is missing. If we are not skilled in business analysis, then we are going to have problems writing good stories, irrespective of whether they have clear 'users' or not.

For example the case given in one of the responses ""As a Solutions Architect, I want Entity X's CRUD events to be recorded in a Message Queue, so that EventPublisher can publish them asynchronously".

The question to ask is 'Why does the systems architect want that to happen?" and keep asking why until we reach a point of value, not a feature. Publishing asynchronously is a feature, not a point of value (i.e. benefit).

So why is it that the architect wants asynch publishing from a message queue? I'll make a guess, for purposes of resilience, maybe. So the story can be re-written as something like.

"As a Solutions Architect, I want Entity X's CRUD events to be recorded in a Message Queue, providing the ability for EventPublisher to publish them asynchronously so that we can be sure that in the event of a system failure we will have automatic recovery on startup, enabling the business to immediately function correctly with no need to manually reset consistency in business systems"

Or something like that. Note the benefit statement as written provides the meat for additional acceptance criteria to better inform the testing effort.

In reality if we are specifying entirety X out it is probably feasible to tie the whole story back to a business user or customer since entity X is likely to relate to some business function or another, which could be detailed in the story.