How to be agile when there's a massive amount of sales / prework / product discovery to be done before actual implementation?

Speaking generally, our product is a user facing portal that displays data from multiple sources. It can take several months to display data from a new source.

The steps involved are:

  • business and legal agreement with the new source
  • discovery to define how they will connect to our system
  • building the interface/technical infrastructure
  • negotiating about collecting
  • analyzing and transforming the data to meet the portal standards and finally
  • displaying it

We are trying to implement agile Scrum with JIRA and it has become a challenge.

Because this pre-work necessary to deliver value to the customer is something the customer does not care about, pre-work cannot be tracked as user stories! A consultant suggested we use tasks instead. But tasks cannot be assigned points so how can they be tracked? Should we use kanban instead of scrum? Then what will be the purpose of sprints?

  • 1
    Can you give us some more information about the teams? Number of teams, size of the teams, roles represented within the teams, is there work that must be done by specific individuals, relevant roles not represented within the teams? May 25, 2019 at 16:57
  • It is one team of 5 developers,1 tester, PO and SM. The tester is not technical so she focuses on user acceptance testing with stakeholders. Some developers are more experienced than others but we are pairing to cross-train. All the developers are their own BAs (meetings, negotiations, analysis, documentation etc). Dev Ops, legal and Tech architect are not part of scrum but their input is necessary from time to time May 25, 2019 at 17:22
  • If JIRA is being a challenge to your implementation, just get rid of it. Remember, processes over tools.
    – Erik
    May 29, 2019 at 5:25
  • 1
    Someone has misinfomed you. All work above the task level should be visible on the Product Backlog, and tasks/stories need not be individually shippable. The Sprint's increment of work (generally the Sprint Goal) is what should be potentially-releasable.
    – Todd A. Jacobs
    May 29, 2019 at 8:20

3 Answers 3



You're letting a tool drive your workflow, and deliberately hiding work rather than making it visible. Both of these are agile anti-patterns. Furthermore, you're not slicing work up in ways that reflect capacity consumed by the Development Team, as opposed to simply tracking external dependencies.

The fix is easy: more transparency, more visibility, and greater collaboration with stakeholders and customers. I detail some of the ways you can achieve this in the sections below.

No Invisible Work, Ever℠

Because this pre-work necessary to deliver value to the customer is something the customer does not care about, pre-work cannot be tracked as user stories!

This is absolutely wrong. Agile frameworks and methodologies heavily rely on:

  • visibility,
  • transparency, and
  • intense customer collaboration.

By hiding "pre-work" or attempting to bury it inside some other attribute of the work, you are actively harming communications and active collaboration with the customer. How can the customer possibly make informed business decisions or trust in the process if, like an iceberg, most of the "real" project is hidden below the surface? Don't do that!

While it's true that most customers won't care about the minutia of product development, it's extremely important that they are able to see "how the sausage gets made." If a feature is difficult to implement, or requires a high level of effort in areas that don't directly deliver value, the stakeholders must see that. When this currently-hidden work is surfaced and visible, stakeholders can make better-informed decisions about what features they value, what resources they can bring to bear, what processes they can improve or impediments they can remove, and whether the cost/benefit or return on investment is still worth it after evaluating the full measure of work involved.

"This is a 40-point story" is not a useful business metric. "This feature will likely take 12 one-week Sprints at an estimated cost of $105,000 in labor to deliver" is a much more useful decision-making tool. Scrum isn't just about completing Product Backlog Items; it's about completing the right user stories, and constantly re-evaluating the process and the prorities!

Tasks are Decomposed User Stories; Sprints Deliver Increments

A consultant suggested we use tasks instead.

Maybe. A task is not a user story, and a user story isn't necessarily a shippable feature. In this specific case, you are allowing your tool to dictate your process. Never do that!

Your process has a whole host of issues, but most of them stem from trying to hide work from your customers. This creates a set of X/Y problems that will lead you to the dark side.

Most customers primarily care about potentially-shippable value, not necessarily features. While a great user story represents a vertical slice of value to the viewpoint character in the story, it may or may not be a shippable increment on its own. Instead, the team should focus on the increment delivered by each Sprint, which is generally captured by a Sprint Goal.

It's worth noting that JIRA is primarily a ticketing tool. It's not "Scrum in a box," so trying to implement Scrum solely through the lens of JIRA is a surefire way to drive your team nuts. JIRA provides no core mechanism for representing a Sprint Goal, or to treat the output of a Sprint as a coherent increment. While you can abuse various features of the tool to simulate those things, the Scrum Team (not the tool) must take responsibility for tracking the right aspects of the framework.

Each Sprint need not result in a formal release. It simply must deliver a potentially-shippable increment of value. There are cases where multiple Sprints are needed to reach an agile release milestone. That's okay! But you can't measure your progress towards that release unless you're tracking all the value-added steps needed to get there. In this case, "value-added" doesn't inherently mean "customer-facing." It simply means work that adds value to the product, and work that is essential to the development of the product adds value, too!

Decompose to Fit the Time Box, and Track Everything

Most product features will have a lot of pre-requisites. When possible, vertical slices that fit within a single Sprint are ideal. That's not always possible. In such cases, you capture the feature as an epic, and then build themes and user stories that will collectively deliver the epic.

In particular, a user story is a coherent bit of product development that:

  1. Meets INVEST criteria.
  2. Contributes to the current Sprint goal.
  3. Fits within a single Sprint.

If you have a story or epic such as "Display data from Faux News" that won't fit into a single Sprint, then you need to decompose the work into measurable increments that do fit, and that work should be visible to both the team and stakeholders.

Maybe the current Sprint Goal is to display stats on every Disney Princess ever filmed. You have some spare capacity in the Sprint, though, so you also take on the story that says:

As corporate counsel,
I want to send over an initial contract to Faux News
so we can get agreement to add them to our portal.

The Development Team might then decompose this into some low-effort tasks. Some examples might be:

  1. Request the corporate counsel write a contract for Faux News.
  2. Validate that the contract has been sent to Faux News by the last day of the current Sprint.
  3. Add a story to the Product Backlog to follow up on the contract status in a future Sprint.

In reality, these sorts of stories are often 0.5 - 2 story points because the level of effort for the Development Team is quite low. They're basically conversations that need to be held, resources to be requested, or tracking activities to be performed. You aren't tracking the lead time or cycle time of the task, but rather the level-of-effort required by the members of the Development Team!

With that in mind, most of the stuff you've defined as "pre-work" definitely belongs on the Product Backlog because it needs to be tracked by stakeholders and by the project. However, I suspect most of the pre-work stories represent dependencies for work the Development Team must do, rather than high-effort work the team must do itself.

As an example, you could redefine a user story like:

# This story is probably wrong unless the Scrum Team
# has a lawyer as a full-time member of the Development Team
# who is actively participating in the Daily Scrum.

As a team,
We need to get a contract from Faux News
so we can integrate it as a data source.

into a more accurate task like:

Email Bob and Susan over in legal about the contracts we expect to need next Sprint to begin working on the Faux News data source.

This turns a misleading and incorrect story about "pre-work" (more accurately, an external dependency over which the team has little control) into a concrete task the team can actually perform. Specifically, the task becomes one of making a request rather than delivering an artifact. This is immensely more measurable, easily estimatable, and simple to track as as done or not-done.

Whether you make each contract request a user story in its own right, or whether you bundle up a bunch of similar tasks into a user story like "request all the current contracts" is up to you and your stakeholders. Finding the right level of granularity is an art, but visibility, transparency, communication, and collaboration are the guiding principles that can help you define the optimum level for your particular project.


The challenge here is to stop thinking about the end solution and start thinking about interim steps that can deliver some (small) value.

For example:

  • We have taken some sample data from the client and uploaded it in raw form to our database - not much value delivered yet, but now the data is available, all be it in a very inconvenient format
  • Next step is that we had some initial conversations with the customer about format and applied some basic data manipulation rules - still not very valuable, but now there is data available in a better format
  • Put a basic user interface on the data - not something that we would ever say is the end-product to the user, but it is something that lets us test the data and do demonstrations to the customer
  • Work on automating a data import - value is that the data can be more up to date
  • Add monitoring and reconciliation - value is that the user can have more confidence in the data
  • etc.

Some possible user stories could be:

As a user I would like to have some of my data available so that I can view it (possible epic, to be further broken down)

As a user I would like to have the addresses in standard format so that I am comfortable viewing them

As a user I would like to have my data reconciled so that I can be sure that it is accurate

As a user I would like to have my data uploaded daily so that when viewed it is up to date

You can still use valid stories, it is just that they may only deliver limited value. The process of breaking the work down this way will enable you to regularly demonstrate progress to the customer and will allow you to iterate.

  • Thanks Barnaby. We had similar suggestions to what you have said . But the consultant said that if a story does not result in something that is potentially shippable/(something the customer would see), then it is not a user story May 28, 2019 at 13:59
  • I suspect your consultant is confusing user stories with minimum viable products. The stories I listed are all potentially shippable and they deliver some value. It is just that a Product Owner would be unlikely to ship them immediately. The reason we include a value statement in a user story is that it makes them easier to understand and prioritise, not because we think each story must be shipped immediately after it is completed. May 28, 2019 at 15:13

As you've noticed, your project is not especially amenable to an Agile approach.

This it not particularly unusual; most projects are not very amenable to Agile approaches. Software projects are the outlier.

As you might not have noticed, your project is mostly not a software project.

(Yes, there are non-software projects that are well-suited to Agile approaches, but I maintain that they are unusual cases.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.