How Long a Sprint Should Be
Data Warehouse and Business Intelligence Teams Benefit from Shorter Sprints
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. I’ve been using my blog to report the questions and the answers. I answered the first question, QUESTION #1: HOW CAN A USER STORY SPAN ALL LAYERS — IS THAT NOT AN EPIC? Now, here’s another frequently asked question and my answer.
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?
LW: I personally think that teams should start out with shorter sprints. If you’re doing an agile transformation and you’re moving towards an agile approach, if you start out with a one-week iteration with really thin-sliced stories, you’ll learn the agile process and you’ll learn what your team can and cannot handle much faster.
A key aspect of an agile approach are the learning cycles. In a traditional data warehouse, you might have two releases a year, and you don’t show anything to the customer until they are in UAT (user acceptance testing). That’s two learning cycles a year. We do these things called postmortems to reflect back on the project and for us to get feedback. But two learning cycles is not that many in a year.
So if you’re a new team starting out with agile, and you go to one-week iterations, you have a learning cycle at the end of every iteration, at the end of every week. It’s going to slow you down, but you’re learning faster. And then you can expand to two- or three-week iterations. The typical sprint length, or iteration length, is two weeks. I have seen DW teams who try to start off with nine-week iterations, but that is not enough learning cycles and you always bite off more than you can chew in your first few iterations. We’re used to doing really big work, not little teeny pieces of work. If you start out with a nine-week iteration, and you work as fast and hard as you can for nine weeks, and you’re doing it in this new mindset with these new approaches, and you’ve got all this overhead of learning with all this process change, and you get to the end of the nine weeks and you don’t hit your goal, it’s really disheartening. And you can lose your business’ attention. You can lose their support.
I suggest when teams start off, they go with shorter iterations, and once they feel they’ve got the agile process down, and they’re working together well, and they’ve got a good mindset shift, then they can expand to two- or three-weeks. Anything bigger than that and you’re shortchanging yourself on your learning cycles.