There have been numerous discussions and even arguments in terms of a better implementation strategy in BI projects. But there is no doubt that more and more teams are adopting agile processes or spirit into the team as of its value. When we have conversations on agile methodology or agile teams we usually start with a created product (requirement) backlog and a perfect product owner (PO). Actually per my finding and consideration, to create a good backlog is not easy – it should stand for the real requirement from the stakeholder who can be a manager, staff, CXO and contractor. It should be clear enough to work for the development team. It represents the future state and is sometimes intangible for the people.
Taking my recent Oracle BI project case as an example, it will showcase the challenges and advantages to adopting agile 
into a traditional Oracle practice team. Agile strategy and technique has brought a positive impact in the project schedule, quality, team velocity, knowledge, customer involvement etc.
Similar to most types of IT projects, there is much challenge in business analysis. For example, the real requirements are distributed in different groups of people and the staff knows most of his/her own part but doesn’t have much sense into the big picture; the front end system is the ERP which comprises of many functional modules and its analysis driven by each function track lead. The usual way is that each lead works with the user separately but there is a lack of integration. The BI system relies heavily on the ERP system which means the common user case should be consistent in both systems such as time/expense approval process. The business users don’t have much insight into what the future system state is and can’t present their real requirements which is indeed transferred to the future state. Inevitably they will need to change as the system is implemented with the new technology and out of box processes. Too many stakeholders can make this complex and inefficient.
We have been implementing the project management in a hybrid model – traditional processes and Agile based analysis, design and delivery approach. The agile model adds much value to the teams. Most of team members are pretty strong in the traditional delivery model such as waterfall planning, budgeting, quality controlling, etc. but few of them had agile sense. From what we learned, the following principles could be taken into consideration for a similar project requirement analysis.
Start with the big picture but take small steps. In an ideal agile (scrum) team, the PO role is really important and key to the success. In our mixed team, the project manager or dedicated business analyst (BA) can be a PO. This role could work with business users in different departments to gather as-is reports/analysis/dashboard and define its high level property like priority, track, average user, delivery phase, etc. At this stage the PO doesn’t need to worry much about data flow, feasibility, or user experience. With the big picture in mind, the BA (or maybe a team) can start on one specific track to drill down on detail requirements. The reason for picking one small part is that the analyst and user will understand their business clearly and deeply step by step.
Create the initial backlog list. Initially creating a backlog and continually maintaining the list is a major activity for agile teams. In the data warehouse and BI world, the architecture could be built upon frond end user requirements or the enterprise process element. Please refer to Kimball model. Which one should be our backlog? I believe there are some arguments around it. In our case we use user reports and analysis requirements as our backlog as that will drive us to continue on design and delivery in the next step. As mentioned in the first point, BA might have begun their work to gather as-is reports when those list are cleaned and being added with new requirement from users. That can be our initial backlog.
Improve analysis process continuously. From the experience we observed, the PO would have to spend lots of time to meet with different groups of folks and have discussions with them. Sometimes the user may change their mind later. The PO can try to improve the process to avoid re-work and reduce the cost. In the meantime, the requirement should be validated and tested out when one defined track is finished. This implies that when POs work on more tracks (aka sprints in scrum), the process can improve. Not only the BA team, but also customers know more about agile and like to cooperate in the same manner.
Manage the activities in iterative way. To define the time boxed sprints is not a must for requirement gathering, but teams can try to plan out their activities such as conversations, meetings, discussions, and documentation in an iterative way. For example, go to build a first track of report requirement by documenting its priority, use case, condition, and user story. Then continually communicate with the stakeholders to reach an agreement. At the end of each day, the team can communicate with each other to discuss progress and impediments. At end of each track, the team can look back and have a quick retrospective talk.
The agile model is new to the business requirement gathering space compared to the design and development phase, but its thinking and idea is wonderful and attracting, why not to have a try?
