If getting real data is slowing you down, you can split your stories along the line of fake (also called stubbed or dummy) data and hook into the real data later. This way, you can at least get some working functionality delivered to your customers for feedback, even if the data is not real to begin with.

When the data is in order, you can circle back and hook it up to the real source so it can be thoroughly tested. This is a way to work around delays in getting real data organized and properly sourced.

In our Recipe app example, some stories for this might look like this:

Another option for this would be to use the original story and simply include the fact that you are using dummy data as part of the acceptance criteria, rather than as a separate story. The problem with this is that you will still need another story to hook in the real data source.

Questions to ask:

• Is it going to be a while before you can get real data to work with?
• Is there a way to move forward with fake or dummy data to get the function working?
• Do you have a good idea of how the data will be structured so you can mock it up?

While this is not something I typically recommend, it can work if you have no other options to move forward.

Static Data then Dynamic Data

This method splits stories by static data first, and then dynamic. It’s another way to get moving without having to slow down to solve more difficult technical problems. Perhaps having dynamic data requires a bunch of servers to be configured, a license to be purchased, data needs to be de-duplicated, or data needs to be input before you can start dynamically serving it. Instead of waiting, you can start with a static copy of the data, while recognizing that the data will be dumped and refreshed once a dynamic data source becomes available.

This is a good technique to use when your data doesn’t change very often, perhaps only on a periodic basis. This way, you can deliver something of value to your end users right away, while working on building out the dynamic data process.

This story split would look something like this:

Questions to ask:

• How often does the data change?
• Will a static copy of the current set of data work to begin with?
• Is there a way for the data to be updated?
• Can you wait to have dynamic data?

This is another option I don’t usually recommend doing because it feels like you’re not taking the whole fully functional vertical slice, but it does enable you to move forward without having to program difficult technical solutions.

You may discover that it’s not even worth it to make the process dynamic, if the data changes infrequently, or you may learn that it’s a high priority to make the data dynamic if it changes often and people want to have the latest data.