Is it a problem when many stories start with: "As the system,..."

Question

I'm a developer on a scrum team and I'm finding it hard to understand and empathize with the end goal when stories start with "As the system". These stories should be straight forward because as a developer I should be able to build to meet the acceptance criteria, but I find they are frequent getting pushed back to me after review because there was some stakeholder's needs that are not being met.

As an example, there was such a story that involved a bunch of edge cases and seemed to be growing in complexity by the day. When I probed deeper to understand why we are covering these edge cases it turned out that there were features being built for one stakeholder and features being built for a completely different stakeholder. Which probably could have saved many communication trips between the PM and me if they were defined as two stories.

In short, should we avoid using stories that start with "As the system"?

Answer 1

Yes. Using 'the system' as a user in stories is bad.

The whole point of the "as a ... I want ... So that ..." Format is to give the developer an insight in to the reason for the requested feature. This should allow them to fill in the gaps in the specifications.

Rather than "make the button red" you would have "as a customer i want the buy button to be red so that I can easily identify it and click it easily"

So when you get the request and you see the background is also red under condition X. You dont just blindly go ahead and make the button invisible.

You should insist that the BA/PM/SM or whom ever, draw up a list of users of the system and that each story should use one of the users from that list.

Answer 2

User stories are an Agile approach to requirements that emphasise end-user value.

All user stories are written in the language of the end-user such that they can be understood by a non-technical person who will instantly 'get' the value the story delivers.

The reason this is done is that it helps the non-technical end-users understand what progress the team is making and to prioritise work.

Something that begins with "As the system..." is not a user story. It is a technical task wrapped up in the user story format.

So where do technical tasks fit in?

Typically the Product Owner will create user stories that signify end-user value. They will prioritise them and then present them to the team as a part of backlog refinement or sprint planning.

The technical team often cannot look at a user story and understand exactly what it is they need to deliver. This is because a user story is an invitation to a conversation. The Product Owner talks the technical team through the user story. While they are doing that the technical team often breaks the story down in to one or more technical tasks. These technical tasks do not need to be understood by the end-users, can be written in a non-story format and can be highly technical in nature.

An an example, say I have the following user story:

As a first time website user I want to register so that I can get access to the website

The technical team might look at that story and break it down in to a number of technical tasks:

Create user table in database

Design the registration pages

Add validation to input fields

...and so on.

There should be few or no technical tasks that do not relate to a story. Even something like:

Set up the development environment

can be wrapped in to the first user story that delivers end-user value.

The goal with this approach is to have:

• User stories that the end-users can understand
• Technical tasks that the technical team understands and that are sufficient to deliver the user stories

Answer 3

User stories should be vertical slices that deliver value to an end user. The system is a mindless machine that doesn't care about value so user stories that start with 'as the system' generally will not help you understand why we are doing something from the perspective of the business or a customer.

So there will be stories where you will write 'as the system' that may at first seem very technically complex or 100% backend that do not have any tangible end user value. Take a harder look and try to really understand why we want the system to do something or behave in a certain way because the system is always designed to interact with a human at some point and help that human make some type of decision.

Answer 4

Yes, as a product owner who writes user stories all the time for a VERY large project that is considered an agile pioneer in our industry, I can say that we would never write "As a system..."

A user story is a story about a user. If you drill down through the logic of why something is needed, there is always a human under there somewhere and that person is who the story is about. Even in cases where you are writing a story about an external service that has to share data with us on the back end, there is a user of that service somewhere, inevitably.

I'm pretty confident about this because our project as a whole has put a lot of effort into the practice of creating useful user stories, and we product owners actually peer review our stories regularly. If one of us wrote "As a system..." I guarantee they would get cut to pieces in the peer review session. Even worse, if the story was actually delivering functionality to two different customers, they would be cut to pieces even worse. Good practice is to cut the story down to the smallest useful vertical slice, and it should always be focused on the needs of one user (or class of users) that is clearly defined.

Also, the fact that your story was "growing in complexity by the day" indicates that there is something dysfunctional going on with your story grooming process. A user story should be kept small to allow for better tracking of team velocity, easier planning, and (in an ideal world) allow for something deliverable (albeit small) every sprint. A user story should be focused on one user, as small as practical, and let go of by the creator of the story once development begins. I have had to change acceptance criteria in-flight (while a story is in development) before, but I am extremely reluctant to do so and will make very clear to the dev exactly why it must be done. 99% of the time, if something new comes up that changes things after the story is in flight, it will simply become a new item in the backlog.

Over all, I really think you guys should probably review how you are approaching story creation, story grooming, and planning.

Answer 5

In short, not necessarily but it does have a "bad smell."

It sounds as the root issue is that they might be poorly written and, more importantly, are poorly understood. I sounds like there needs to be improved communication regarding the purpose and goal of these items.

Answer 6

The point of saying "As a .., I want to" is to show who the story helps, and give info to the developer on who to ask to complete it. Saying "As a system" implies the system cares (really?) and is actually solution-ising as part of the requirements (you are assuming this is some kind of non-interactive piece).

You need to think about who you need to help, and write the story from their point of view, then think about how you can solve it.

Answer 7

I would argue that it all depends on what is the goal of this particular requirement. There are some cases or requirement types which we could consider here, e.g.:

• stuff that delivers value to an actual user of the system be it a human being (As a teacher ...) or another system (As SAP, I need a correlation ID for each request I make to your back-end so that ...). As the system could fall into the later type, it all depends on who or what is the actual user of your product. Looking at your question and example, that is most likely not the case. That's why I'd advise to try and focus more on user perspective and not use this format.
• stuff that also delivers value but throughout the whole product. These might be various types of non-functional requirements or constraints which must be taken into account when developing the product. Not the case either.

As a side note, I'd say your question touches a very broad topic. Use whichever approach to documenting requirements that brings clarity to your development process, reduces confusion throughout involved parties and doesn't involve unnecessary overhead. I intentionally haven't mentioned explicitly focusing on documenting value here - not because it's unimportant, but because focusing on user value can be achieved in a number of ways and documenting the "so that" part of user story and avoiding "as a system" stories, is just one of them.

Answer 8

Yeah that is just wrong, I would reject it as a requirements phase defect.

Consider the problem User Stories try to address - inexperienced people attempting to write Use-Cases that just enumerate functions and do not consider the business purpose behind the requirement.

Then consider the problem Use-Cases attempt to solve - inexperienced people attempting to write functional requirements by just enumerating functions and not considering the business purpose behind the requirements...

It is not that an actor cannot be a computer system, it's that the labeling does not link to a real world business purpose.