When DW/BI Teams Go Agile

Story Slicing

Four Frequently Asked Questions

I recently presented a series of webinars on “Writing User Stories and Slicing Epics for DW/BI Teams” for Cutter Consortium, where I am a senior consultant. After each webinar, I addressed questions from the audience. In this blog, and upcoming blogs, I will share commonly asked questions and my answers.

Question #1: How can a user story span all layers — is that not an epic?

LW: I’m going to refer to figure 1 — thin slicing points. This is a standard looking DW set of DW/BI layers all the way from source to BI front end.

Figure 1 — Thin Slicing Points

When we thin slice, there are all these different opportunities as go through each of the layers, to make decisions about how deep into each of those layers we are going to slice. And we must ask ourselves: How can we shrink each step? One example is to do change data capture as a follow on story, instead of in the staging layer. Another example is to do data hygiene, or to pull the data all the way through to the BI layer, without doing data cleansing. You might want to have your business look at the data before deciding whether or not to do data cleansing. If when you pull the data all the way through, and your business sees that only .1% of this field has a data quality issue, they may say “That’s fine. That’s within tolerable limits. You don’t need to ever cleanse that data.” You’ve just saved yourself some work and some time and you can move on to something of more value. Each of these examples are ways you can shrink each step and come back and do it later in a different story, if that adds value.

I’ll admit it can be very confusing to hear about all of these layers and it can feel really overwhelming. What I can tell you is that there are lots of teams doing very complex data warehousing work that adhere to this architecturally complete concept. And there are other teams that don’t necessarily adhere to it. I would say that what works best for you, and what delivers value to the business, should be your primary focus.

I have seen lots of teams that split stories between the data warehouse (DW) and the Business Intelligence (BI) layer. If they don’t have some architecture going across — some planning — that spans both of those teams and has them coordinated, the data warehouse team ends up working in a silo. The value, from when you talk about what the business needs to when you deliver the value, can take a very long period of time. I’ve seen teams take nine weeks to three months to deliver what is, in essence, a story from the business’ point of view. You lose your business’ attention. They don’t feel like they’re getting value very quickly.

There are ways to manage this, though. If the DW and the BI teams are both working on the same concept, or they are one iteration lagging, maybe that’s soon enough for your business. Maybe if you have iterations of two weeks, and you talk about it in week one as a whole concept, and if DW does their work in weeks one and two, and BI does their work in weeks three and four, and the business sees it a month later, if the business is delighted, than fine. But if you lose your business in that interim, then it’s a problem. You need to think about slicing thinner across these iterations.

Coming Up on Lynn’s Blog:

Lynn Answers These Popular Questions:

• Q2: In regulated industries, such as medical devices, how are the regulatory requirements taken into account? Releases are difficult to coordinate when there has to be a definitive implementation to draw a line in the sand from a documentation standpoint.
• Q3: What’s an example of good acceptance criteria — outside of that the report should match the mockup/data should be accurate?
• Q4: What is your recommended sprint length for a data warehouse team given the fact that it takes longer to deliver a Data warehouse solution?

Questions or comments about Slicing User Stories? Chime in!