1

We are integrating our portal P with another third party web application W. The W will be displayed in our portal inside a modal popup.

One of the obvious user stories (let's call it US1)

As a user U when click a button B, W should be displayed as a popup and the certain information set 'IS' should be pre-populated so that I can review the information set 'IS'.

Now to pre-populate information set IS, we'll need to create a set of APIs and integrate at the back-end to send the information from our portal P to the web application W.

The question I have is, should the creation of the API be a system user story or a task?

The work can be done in a sprint but the API creation and integration will probably me multiple tasks. Also completion of this integration blocks the subsequent user stories in the third party web application.

So should I write a system user story (lets call it SUS1) and tasks like so ?

As a portal P I should be able to send information set IS to third party web application W so that the user U can view this information.

This will obviously require creation of sub task T such as

"Create API A"

Or should I just create a sub task T for the user story US1.

The team here is more comfortable with calling everything stories so that they can easily view their activity in the sprint burn down and especially communicate and show that subsequent user story US2 is dependent on system user story SUS1.

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
user9445
  • 455
  • 5
  • 15

2 Answers2

4

Creation of the API is an infrastructural concern that should not be visible on stakeholder (or end-user) level. Thus you should create a task as a means to implement the user story US1.

But!

You should partition your system vertically, i.e. the task should require implementing no more API than necessary to make US1 work. You should implement the rest of the API along implementing subsequent user stories.

A natural consequence is that the incrementally built API will not have the best design possible. Thus, at each step you should refactor taking into account all user stories implemented so far. This is much better than BDUF (Big Design Up Front).

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
2

User stories are written from the point of view of end users and describe what it is they want to get from the product. They do not describe how the implementation will be done.

What you have described is not a user story, instead it is a combination of several implementation tasks.

An example of a user story might be:

As a portal user I want to see today's weather information so that I can know what the weather will be like today

Once this user story is assigned to a sprint the development team may well break it down in to a number of technical tasks. This would include the creation of an API sufficient to deliver the user story.

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