I have a use case where we are following Agile (Scrum) and as part of our delivery we need to do some research work. For example:

1) Open a source/sink data pipeline (research)

2) Import data into new area

3) Validate

4) Cleanup

These are sequences. but without completing no.1 above, we really cannot proceed for 2-4 and do a release.

In my mind, the agile way would be to treat no. 1 as a different release item since we are releasing the pipe for usage. So, we should be storyboarding on releasing the new pipeline

The work for no. 2-4 above should be classified as a separate product which can still be storyboarded, but they are not fleshed out for release until the pipeline is released.

Are we thinking this in Agile way ?

PFA - I tried to represent how it looks like initially from our PoV. It's a crude representation of things as they are now.

enter image description here

  • "Discovery" is really a story spike, whether it takes a whole Sprint or just part of one. Trying to pin down ahead of time what work will be stuffed into which Sprint (instead of doing iterative, just-in-time planning) is where you're sliding off the rails of agility.
    – Todd A. Jacobs
    May 29, 2020 at 15:04

3 Answers 3


Scrum promotes an iterative, incremental, and adaptive approach to releases. In effect, what you are asking is if you are taking this approach and the answer is probably, possibly, and likely not. I'll explain:

Iterative: By working in sprints, you are working in iterations, which allows you to frequently review your progress and adjust plans as required. I expect you are probably doing this.

Incremental: If you are creating a potentially releasable version of the product each sprint, you are working incrementally. It's hard to say from your diagram if you are or aren't. If you build the pipeline, is that a potentially valuable increment of the product? If so, you are working incrementally. If not, you aren't. It is, of course, not binary. Perhaps the pipeline isn't working incrementally because the team doesn't see a good way to. They just need to get that done. After that, they can release increments of the product. Is that perfect? No. However, it's way better than not working incrementally at all and the team shouldn't get too down about it.

It is also worth noting that if you are releasing an increment every 3 sprints, you are still working incrementally. You are violating rules of Scrum though. Scrum would promote smaller increments.

Adaptive: This refers to the ability to effectively pivot as circumstances change. In the most extreme cases, an adaptive approach might require you to throw out your entire backlog based on what you learn in a sprint. More commonly, these adaptations are adding missed features, changing features, identifying new solutions for known problems, etc.

There is one big red flag in your diagram on this. Cleanup is at the end. This suggests that you are locked into delivering the solution in a set way from sprint 1 to sprint x. Of course, that may just be a problem with the diagram. In a more adaptive approach, I'd often see different areas of data and I'd want to build out the pipeline, transfer data, validate it, and cleanup in one sprint. If that's too big, I'd like to take on a smaller data segment. This would let me complete a full increment that left me in a clean state so I could pivot wherever I needed to next sprint.

  • We are releasing a full feature every 2 sprints or so. Even though it sounds like Incremental, it's more iterative as you have guessed. The concern we have is that every quarter we have between 6-8 sprints (bi-weekly). Every sprint has a goal, and a product that's being delivered. To me, it's sounding more and more like a spike which we should be doing before the beginning of new quarter. Does this sound reasonable?
    – ha9u63ar
    May 30, 2020 at 15:02

I think you're overthinking this. Do you want to know what agile is? Agile is two things. First, the Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

And second, the twelve principles.

Therefore, whenever you come across any issue (such as this, but really anything), and want to approach it in an agile way, then you only need to follow these steps:

  1. Look at the issue.
  2. Look at your organization/situation.
  3. Compare them to the four values and twelve principles.
  4. Pick a way forward.

Because of that second step, getting advice from strangers on the internet should always be taken with a grain of salt.

That being said, here's my take on your issue - got your salt ready?

It doesn't matter. Either approach could be considered 'agile', so just do it in whichever way makes more sense for your team.

  • The issue here is that Agile is a process for the team, not the other way round. The internet and s/w development seemed to have overpowered it for the latter. We are dealing with a team whose projects are more to do with maintenance/update rather than creating a new product. The storyboarding examples and guidelines are befitting for new product more than maintaining/updating/patching things - these are more kanban sort of thing. That's where the business is pushing for a change.
    – ha9u63ar
    May 30, 2020 at 15:07
  • @ha9u63ar I'm not sure what the problem you're having is, then. Your question was "Are we thinking this in Agile way?". Does my Answer not answer that? If Kanban suits your work better than Scrum, switch to Kanban. Where is the pain point?
    – Sarov
    Jun 1, 2020 at 13:03

The agile approach is to deliver incrementally.

In your example, it would be to:

  • Open a source/sink pipeline that delivers some data
  • Import some data into new area
  • Validate some data
  • Cleanup some data
  • Modify the source/sink pipeline so that some more data is delivered
  • Import some more data
  • etc

Ideally the first piece of data will be sourced, imported, validated and cleaned-up in the first sprint. This is likely to be a limited data set (possibly even just one field).

In agile we would call this a thin vertical slice.

The intention is to deliver some value at the earliest possible opportunity. It also helps to de-risk the delivery by tackling every layer early on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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