User stories delivery issues

Question

Working in Agile manner, project team routinely delivers parts of software, described in User Stories. Upon each Sprint a working software is delivered, with some additional features added.

The advantage and drawback with User Stories is that it describe completed feature. Developing code for User Story has several sub-tasks, and problem is some tasks cannot be delivered within Sprint, often until end of the project. Such tasks are like: integration with 3rd party API, dependency on external system.

For example, web development project:

WEB-122: "As a customer, I see Order Confirmation screen, where I can review items ordered, amount total, tax information. I click on Pay Now button to be tranferred to SomeExtravagantPaymentService page and finish payment"

Issue: client is only negotiating with SomeExtravagantPaymentService and cannot provide login details. Also, service does not provide beta or sandbox option for texting (in Europe it's quite common) -- dependency on 3rd party API.

For example, home construction project:

DWELL-234: "I want to have electricity and lightbulbs in basement installed, controlled by switch".

Issue: even if switches and lightbulbs installed properly, this user story cannot be finished and tested until electric company connect house to power line, which may happens on later stages of development. Dependency on external system.

Problem with described User Stories is that such stories cannot be finished during several sprints and will be dragging from sprint to sprint. Client will not receive finished product after sprint. How this situation could be managed ?

Answer 1

Problem with described User Stories is that such stories cannot be finished during several sprints and will be dragging from sprint to sprint.

You need to break down your stories further using the INVEST model. Write your stories in a way so that each one is self contained and there is no or minimal dependency on other factors.

So your story can be re-written like this:

WEB-122a: "As a customer, I want to place my Order, so that I can get my required items"

WEB-122b: "As a customer, I want to review my Order so that I can verify the items ordered, amount total, tax information"

WEB-122: "As a customer, I want to pay for my Order, so that my order can be processed (and delivered to me)"

In ideal cases, a user story should be completely delivered in one sprint, it should not drag on.

Answer 2

I think the problem is that you haven't broken down the story. When you write a story try to break your high level requirements into smallest level possible.

Example in the case which you have mentioned:

As a customer, I see Order Confirmation screen, where I can review items ordered, amount total, tax information. I click on Pay Now button to be tranferred to SomeExtravagantPaymentService page and finish payment

The story can be further broken down into smaller stories like:

1. As a customer, I see the Order Confirmation screen, where I can review items ordered, amount total, tax information
2. "Pay now" button which will be transfered to SomeExtravagantPaymentService page
3. Complete payment

So in this case, once you are done with Confirmation screen, you can deliver that to your client. You can take up SomeExtravagantPaymentService page after that once your client confirms it. Till that it will be in product backlog and will not be taken to sprint.

This way you can keep track of your story and you can deliver complete user stories to your client at the end of sprint and you can avoid carrying over a task to the next sprint