0

Note: I read the 2 following questions :

Here's the "short" story :

I am a product owner assistant working with a team of business analysts for a bank (the client). The project (a multiple applications system) delivers reports for final users. The client wants us to help them in the way they write "stories". (better cutting)

At this point, Business analysts provide sequence diagram. The way they write stories are between technical implementation and ("user") stories. Moreover, the stories are not INVEST because its follow sequence.

An exemple :

Feature :

As a FO user (in real life it's a system)
I want to ensure the loaded database contains all mandatory data in a correct format
So that I can generate a valid report for my customer

Scenario :

Given: I have loaded the database
When: It contains all mandatory data for proper report generation
And: The amounts formats do not fit the report generation rules
Then: I can convert the amounts formats (and go to the next step)

Here are my questions :

  • Can we consider these stories as technical user stories ?
  • Should I have to consider that we cannot write "user stories" but persist with specifications ?
  • Do you have good inputs to convert sequence diagram to user stories ? Should i consider it as scenarios ?
Community
  • 1
  • 1
benoitr
  • 6,025
  • 7
  • 42
  • 67
  • Possible duplicate of [How to write User Stories for technical implementation details?](http://stackoverflow.com/questions/20581167/how-to-write-user-stories-for-technical-implementation-details) – Dave Hillier Jul 27 '16 at 09:18
  • Possible duplicate of [Writing user stories for internal technical tasks](https://stackoverflow.com/questions/1707080/writing-user-stories-for-internal-technical-tasks) – TylerH Aug 19 '17 at 23:34

3 Answers3

4

There is no such thing as a 'technical user story'. This is why:

The idea behind user stories is that they are easily understood by the end users of the product. In your case this is the users who want the reports your system is generating.

This is done for a specific reason: it is to make it easier for the end users of the product to understand progress. If your story contains technical details that the end user does not understand then the fact that the story is completed means little to them. If, however, it is written in their language then they can see the value that has been achieved by completing the story. Think of user stories as an effective way of reporting progress to the end users of a system.

Now it quickly becomes clear that a user story is not going to be sufficient for a technical team to deliver the required work. This is why the delivery team often takes the user story and breaks it down in to technical tasks. These technical tasks describe how it will be implemented and are typically added just before the work begins.

In your example the user story might be:

As a bank current account customer I want to see an end of year report of my account so that I can do my tax returns

And the team might add the following task that is associated with this user story:

Load all mandatory data in the required format and convert any data that is in the wrong format

Now imagine that the story has been completed. I could walk up to a random bank customer and tell them that the story has been done and they would understand what I meant. They would immediately grasp the value to them of having this new report. Whereas if I told them about the technical tasks it would mean nothing to them.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
1

As you've already read from the other posts, user stories shouldn't be technical. I would suggest sitting with the Business Analysts and helping them write INVEST stories, training them to see how stories should be from the perspective of the user and showing business value. In the end, system-to-system user stories don't make sense, but the client system will have users so the stories could be written from their perspective (and these users shouldn't need to care what other systems are being depended upon). Stories should also be a bit more specific/defined than your example (eg. I've taken profit-and-loss as a specific below).

I don't know the context of your systems, but as an example:

Feature

As a user of the client system
I want to be able to format my financial results correctly
So that I can generate a valid report for my customer

Scenario

Given: Profit-and-loss values have been calculated
And: The amounts formats do not fit the report generation rules
Then: I can convert the amounts formats (and go to the next step)
gezzahead
  • 1,196
  • 1
  • 11
  • 20
0

How to write “User” Stories from system to system?

You can't systems are not users.

Can we consider these stories as technical user stories?

As stated in the questions you've referred to, and in Barnaby Golden's answer there is no such thing as a technical user story, or even just a technical story.

User stories are supposed to be about communicating between the user and the developer. You example story assumes implementation details about the possible solution.

Should I have to consider that we cannot write "user stories" but persist with specifications?

No, you and the business analysts should try to get out of the way of your developers. Instead of writing user stories, instead focus on providing your expertise of business processes to the team.

Ideally, the developers should be able to talk directly to customers, understand the value of features requested and decide on the best implementation.

Agile teams work to deliver vertical slices of functionality, which means that they should be empowered to deliver end to end.

Do you have good inputs to convert sequence diagram to user stories? Should i consider it as scenarios?

No, this doesn't really make sense, again, sequence diagrams are about systems, not users. Therefore its not a user story or even scenarios.

Dave Hillier
  • 18,105
  • 9
  • 43
  • 87