What we should do with tasks which estimated time bigger than sprint?

Question

I know, we need to separate this task to several subtasks. But what we should do, if further division of this task have no sense? What if all of resulting subtasks will have no business value until all of them will be done and integrated together?

Maybe it seems that this is a little artificial situation, but sometimes it could happen (especially, if you have short sprints).

Example from my practice: we have User Story to allow user make payment from our system. As a part of this story we have task to integrated 3'th party payment service to our project. So, all subtasks of this task are absolutely technical and have no buisness value.

So, I see only three ways to solve this problem:

• Separate business valuable task to several technical tasks. But in this case we will not make something useful in first sprint and we will not have anything to show in review.

• Make all sprints bigger. Maybe our sprints too short and it will be better make it bigger. In this case we will reduce feedback speed, but situation like I described below can never happen again.

• Make current sprint bigger. As I know, this is not scrum-way solution. Scrum like constancy (make Daily Scrum in same place and same time, fixed limited time-boxes and so on). Plus, it will be hard reconcile new rewiev day with stakeholders. If you have another teams, that work on same project, problems with this solution will be much bigger.

Which solution is better? Or, maybe, somebody know better way to solve this problem?

Answer 1

Look for ways to deliver limited business value initially

...even if it is not something that you can actually use.

Taking your example, if you are going to accept Visa, MasterCard and PayPal, you can first implement PayPal (or whichever is easiest to implement) and then have separate stories to add Visa and Mastercard.

If you are going to accept recurring payments (say, a monthly subscription), you can first implement single payments and then add the recurring payments in another sprint.

Here are some tips for splitting larger user stories:

Patterns for Splitting User Stories

8 useful strategies for splitting large user stories (and a cheatsheet)

"Make current sprint bigger" is not a good option. In addition to the problems you listed, you cannot establish a decent team velocity if you keep changing the sprint duration.

"Make all sprints bigger" is a possible option, if you keep running into this kind of problem often, after making all efforts to split larger stories.

Answer 2

First off, let's address the practical matter: if you are in a planning and you have a story that is the highest priority but you don't see how to break it down and retain business value, it's better to break it up technically and move forward than to a) spin your wheels on that story or b) make disruptive changes to the structure like changing sprint length.

That said, there is a common misunderstanding in Scrum that for a story to be valuable and shippable, it's must be a complete, production-ready feature. To use your payment example, the way most 3rd party payment systems work, there's some work that goes into hooking it up and a lot of work that goes into handling different possible scenarios that could come up. The payment functionality definitely isn't done until it's fully integrated, but there is still value in the pieces. If you take it to the point that a credit card, entered properly with enough funds available works and everything else is treated as a general error, there is definitely business value there and it is shippable. Granted, the circumstances where you'd release this to production are few and far between, but you could if it was warranted.

The tough thing with these stories is that it does require a some time and collaboration to work through. If you'd like a technique to try, you can take a look at my blog post on this topic. What it really boils down to though is that you need to collaborate with the team helping to show the pieces of the process of implementing the story and then the PO weighing in on where they see value.

Answer 3

sometimes it happens, you'll have features that cannot be delivered entirely during one sprint. you should consider splitting it into subtasks, which will not deliver business value themselves, but they can be demonstrated and verified after each sprint.

considering your payment system example, we can have three sprints for delivering final results:

1. develop mock gateway and functions providing default payment scenarios with mock
2. develop advanced payment scenarios using the mock (refunds, etc.)
3. develop real gateway and test integrated scenarios.

the order of sprints can be changed to bring forward the most risky part, but still, the whole functionality will only bring business value if those scenarios are covered to some extent. but after each sprint, you'll have something to demo.