How To Manage Regulated Documentation in Agile Projects

FOUR FREQUENTLY ASKED QUESTIONS

I recently had the honor of presenting 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. Last week, I answered the first question, QUESTION #1: HOW CAN A USER STORY SPAN ALL LAYERS — IS THAT NOT AN EPIC?

Here’s another popular question and my answer.

QUESTION #2: 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.

LW: That’s a really good question. And a common one. In regulated industries, such as medical healthcare and financial industries, there are a lot of questions that come up. I believe you really need to try and include that information in your definition of done. If you can fill out your documentation a little bit at a time, it makes it not such a big task to fill it out in the end. Including your regulatory requirements in your definition of done is one way to manage it.

Another way that I’ve seen teams do it is to have what they call a hardening sprint, which is useful for Data Warehousing teams because DW teams might do pre-production testing, or production-level testing, or they might do load and stress testing during that time — things that may be difficult to do every couple of weeks given your data volumes and maybe your technical infrastructure can’t support testing on huge data volumes every couple of weeks, but you do have a test environment where you can load lots and lots of data and really pound it. A hardening sprint would be right before your release and during that hardening sprint is when I have seen financial institutions, in particular, take that time to really meet all of their regulatory requirements.

You have to step back and think creatively and look at values and principles. You have to say that your goal is to deliver value to the business and that value is defined by the business, not by the IT team, and you want to deliver it frequently and consistently. So if you do a release every 3 months, and you need to take a hardening sprint to work on meeting regulatory requirements, typically your business doesn’t mind because they understand. They’re part of that business and they respect that the regulatory requirements are there for a reason and you can’t get out of them. So you have to do them.

COMING UP ON LYNN’S BLOG:

LYNN ANSWERS THESE POPULAR QUESTIONS:

• 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 Done? About managing releases in agile? Chime in!