What to do with epic technical stories?

Question

I have a lot of stories of the type: "As a passenger, I want this plane to fly so that I can get to places". The amount of work that the end user doesn't care about from this point on is enormous. Obviously the team will have to do a lot of work before the plane flies but the customer will just be waiting and getting nothing until the plane actually takes off. How would you break this into smaller stories that add value to the customer so you can deliver something at the end of each sprint? How is a non technical product owner going to be involved in writing stories or thinking of fit criteria? How would a sprint review look like?

Edit: clearly, my plane example wasn't the best. Let's try this one: "As a customer (in an online shop) I want to be able to pay my cart using MasterCard so that I don't need to get a Visa". This is a very concrete and precise feature but the technical work required may exceed the sprint length and add no value until it's actually done.

Answer 1

• As a passenger, I want to be able to board a plane.
• As a passenger, I want to comfortably sit in a plane for a few hours.
• As a plane, I want to be able to take off.
• As a plane, I want to be able to remain aloft for a few hours.
• As a plane, I want to be able to safely land.
• etc.

There are lots of things that an airplane does, and it takes a minimal amount of thought to enumerate them.

The amount of work that the end user doesn't care about from this point on is enormous.

The bottom line is that if the customer and/or product owner don't want to put in that minimal amount of thought, and just want to wave their hand and say "tell me when it's done", they that customer and/or product owner is effectively relinquishing control of the direction of that product to you.

One of the main reasons agile methodologies exist is to provide direction and control to the customer and/or product owner. If they don't want that control, then it sounds like agile isn't the right fit for them.

Someone, somewhere is managing those individual features which contribute to the product as a whole. That someone might be the customer, might be the product owner, might be the company CEO, might be the development manager... might even be the most junior developer on the team. That level of management and decision-making exists. Any member of the overall team who absolves themselves of the responsibility of managing it simply delegates that management to other members of the team. If everybody absolves themselves of that responsibility, then it falls on the most junior member of the team by default.

Which is a pretty silly place to put such management decisions, but it happens more often then you'd think.

As an example, consider the simple act of prioritizing work items. Let's say you have 50 individual work items that need to be done on a tight deadline. It's entirely possible, perhaps even likely, that they can't all be done in that time. So they need to be prioritized.

When upper management is asked to prioritize, if their response is "everything is top priority" then what they're effectively saying is "you go ahead and prioritize it for me." Given that you can't do 50 things at once, prioritization must happen simply as a matter of reality. By choosing not to make a decision, the product owner implicitly (perhaps even unwittingly) delegates that decision to other team members.

Answer 2

Let't try this one: "As a customer (in an online shop) I want to be able to pay my cart using MasterCard so that I don't need to get a Visa".

This is an excellent example. It's a story whose components are opaque to the PM, but probably has several tasks underneath it to the developer.

What do you do?

You sit down with a developer (ideally, the one who will actually be doing the work), and ask them just talk through how they'd go about doing the story, writing down what they say as you go (rough notes are fine here, you don't need every word). When they're done, take each sentence or topic and ask how long each one will take, and what their level of confidence is in their estimate (confidence level can just be a sentence, it doesn't need to be a number).

If any of the time estimates are too large, ask the developer to go into more detail about that specific task and see if it's something that can be broken into smaller ones. Same for tasks in which the developer has little confidence in their own estimate.

These time estimates can then be used to create a timeline, which in turn can be used to track progress.

Which brings us to another question:

How would you break this into smaller stories that add value to the customer so you can deliver something at the end of each sprint?

Not all individual tasks have benefit to the customer. If the overall story does, as in the Mastercard example, then you can report a percentage of progress toward the customer-facing end result. If the overall story doesn't (like say migrating to a new database), then you can decide whether or not to educate the customer about the change, depending on how technically savvy they are, and whether there are knock-on benefits from the change.

Answer 3

One of the things I like to do is to pretend that we're not writing software, or that the software is just a very thin veneer on some other manual process at the back end. Sometimes it might be useful to pretend we're just doing 1 customer, or 1 bit of the journey.

You could imagine having a situation where people entered their card details and it was dealt with manually. Or boarded a plane, but had no assigned seats. I'd start breaking the stories down like this:

• The customer can pay by master card (manually, storing all details, which we know is bad).
• The card details aren't in plain text and easy to copy.
• The payment is automatically sent to Master Card (without validation).
• We wait to see if the payment is accepted before continuing (validation).
• The customer gets a chance to redo their details if they're wrong.
• The customer can optionally store their details in their account.

And we can add validation, etc. And for the plane, assuming that making planes fly is the new thing you're doing:

• The plane can take off and land.
• The plane can carry enough fuel for its whole flight.
• The plane can report the level of its fuel.
• The plane can report altitude, speed and angle measurements.
• The plane can seat people.
• The plane can carry baggage separately.
• People can get out of the plane easily in an emergency.

etc.

Fortunately software is a lot easier to change than planes.

You can see that these are not technical stories, even though the implementation might be heavily technical. The customers can clearly see the business benefits of each stage. If you have trouble thinking about those business benefits, think, "What would happen if I didn't do this? When would the first situation where the business noticed actually be?" That will help you work out how to describe them to the business in ways which sell their benefits.

You can split the story by only considering particular outputs, or particular inputs, or particular aspects of behaviour, or different customers or personas, or just split off one single scenario at a time.

The most important thing is to do something small which will enable you to get feedback quickly, either from the business themselves or on the technical feasibility.

Answer 4

I wouldn't say that it is a technical story.

Technical stories refer to technical debt, investigations, spikes or infrastructure usually.

It is a common huge user story that should be developed and it is responsibility of the Development Team (developers, QAs, BAs, ...) to estimate it right and notify PO about its complexity.

It looks like a good candidate for splitting into smaller stories.

There are many techniques how to split user stories:

• How to split a user story (Agile for all)
• How To Split User Stories (InfoQ)
• 8 useful strategies for splitting large user stories (and a cheatsheet)

How is a non technical product owner going to be involved in writing stories or thinking of fit criteria?

It is a responsibility of the whole Scrum Team (Development Team + PO + Scrum Master) to split it into smaller stories that can be finished within a Sprint.

And PO is responsible for setting right priorities to these small stories and set up delivery date.

How would a sprint review look like?

Despite the fact that the whole functionality of the epic (module, sub-product, release) is not finished, development team has worked the whole sprint and if you ask them to show the results, they will show. It is pretty enough to get feedback from PO and step into the next sprint.

The amount of work that the end user doesn't care about from this point on is enormous. Obviously the team will have to do a lot of work before the plane flies but the customer will just be waiting and getting nothing until the plane actually takes off.

After each sprint increment should be "Potentially Shippable" (Done). But if your team works on a really big epic then only PO can decide when the version meets requirements for "Minimum Viable Product" (Shippable) and is ready to be delivered to users.

• Does "Done" Mean "Shippable"?
• Difference between potentially shippable product (PSP) and Minimal Marketable Feature (MMF)

"As a customer (in an online shop) I want to be able to pay my cart using MasterCard so that I don't need to get a Visa". This is a very concrete and precise feature but the technical work required may exceed the sprint length and add no value until it's actually done.

For every single project/product an answer will be different.

Let's say that we have an implementation for Visa an we want to support Master Card also.

I would raise the following questions before puling story into the sprint:

• Do we need to change UI? (UI can be developed separately from the server side and in different sprints.)
• Do we know how to add support of Master Card? (If team knows nothing, there is a good practice to allocate time in previous sprints for investigation/spike. It is a real "technical story", usually time-boxed and can be finished within one sprint.)
• Is it needed to refactor implementation for Visa to extract common interfaces? (It can be done before as separate story)
• Can we start working on this story immediately?
• Can we estimate it? (When team cannot estimate the story it a sign that it shouldn't be pulled into sprint and should be either clarified or split into smaller one steps)
• Is it possible to split the whole payment workflow into steps? (How many new screens/pages/steps should be added? POs usually are OK when stories are developed incrementally an they can see at least part of the functionality. It do make them confident.)

Answer 5

I'll address your edited story instead of the original as I think I can get to the point better there. Let's start with the golden rule:

You should do no technical work that is not providing customer value.

That sounds like something that has to have exceptions, but it's going to make you justify why you're doing the extra work.

With your story about Mastercard over visa, let's start with two stories (and I'm definitely making some assumptions about your system):

As a customer, I would like the site validation to accept Mastercard numbers so I can enter my credit card number (I'm assuming number validation here).

As a customer, I want to be able to authenticate a transaction with my Mastercard so I can use this type of payment method.

The first is independently releasable (though I wouldn't because you'd have a site that accepts the card and then can't process it). The second does the bare minimum to process that card. In my experience, this is probably adding an extra argument to a function and accounting for it in the call to the card processor.

With these two stories, you have your happy-path minimal feature. It will not have frills, like highlighting a Mastercard logo to indicate to the user it understands the card being used. It will also not have failed card handling. Again, the feature is releasable, but if you release it is a business decision. In most cases, you wouldn't because sometimes people's cards are declined and you want to handle that. On the other hand, maybe a big customer wants to make the largest purchase your site has ever had and releasing it means they can submit their order. Then, you probably would.

Now you've got all your frills and your decline handling. The declined card handling is time consuming, so you might break that down further. Instead of having a story that reads:

As a customer, I would like the site to give me a helpful message with my card is declined so I know how to proceed.

you may instead of a number of stories like:

As a customer, I would like the site to indicate when the data I entered is invalid so I know to correct the data and try again.

As a customer, I would like the site to direct me to contact my financial institution if my card is declined due to suspension so that I can correct the problem.

As a customer, I would like the site to indicate when my card was declined for balance reasons.

The two advantages here are that 1) it breaks up the story and 2) it lets you prioritize your work. Also, if you look back at that golden rule, maybe you decide that the customer doesn't derive value from knowing that their card is suspended. If it has no value to the customer, cut that story out and let those decline codes fall out to a default decline response.