I have assisted several BI and non BI teams in establishing their Agile process. One of the common questions is “how long should our sprints be?” By the book, Agile sprints are 30 days. In my opinion, this is a bit long. With mature teams I generally recommend a 2 week sprint cycle. This seems to be enough time to deliver some real functionality, but not so short that you feel like you are always planning.
That being said, I start most teams off with a 3 week sprint cycle. For new teams, this seems to work better while they adjust to the new process. Before a team can shorten their sprint cycle, they need to nail down some fundamentals.
I would recommend getting the following items ironed out before adjusting your sprint length:
- Write clear user stories. This includes understanding the business priority, acceptance criteria and what needs to be done to get there. Making sure that expectations are clear across the entire team.
- Establish a build cadence and process. This would include doing builds on a set day or days each week and passing that on to QA. All builds don’t have to happen at the end of the sprint. I find teams work best when they have a consistent rhythm to change deployment. This would also include automating the deployment.
- Establish your QA processes. Be sure that the numbers you send out are validated. Nothing kills a BI team faster than a lack of confidence from the business.
- Establish Data Quality processes. This is different from #3 as it is an ongoing process. This should be an automated process that alerts the team to anomalies. Even basic data quality like “did our processing finish last night?” is a good start.
- Ensure cross team development. This is a tough one that goes a bit against being efficient. In order to be more agile, you have to have a development core that can take on different areas of the BI stack. Both from a tool and business perspective. If one developer is the guru of an area, your velocity is capped in that area. The team should work to cross train as much as possible. Live out of your comfort zone.
Shortening your sprint length doesn’t make a team faster. Doing the things above makes the team faster.