Approach to effectively apply Agile to a Data(ETL) Project
Current state: Business Requirements document(BRD) is being created for Data Project(ETL), and we know there are around 20 KPIs to be created in PowerBI as an outcome post ETL.
Ask is as below:
- We need to breakdown the requirements in BRD into Epics, Features, User Stories
- Apply Agile methodology for successful Implementation
My thoughts of First ask.
Can you please advise, if you think there could be a better approach from your experience.
- Group similar KPIs and call this an Epic, lets say we end up having 2 Epics for delivering 20 KPIs
- Each KPI will be a unique Feature under each Epic
- Each Feature can then have User Stories required to fulfill the Feature(KPI)
My thoughts of Second ask.
Can you please advise, if you think there could be a better approach from your experience.
Apply Scrum as the Agile practice.
-
The Product Owner to create one Functional User Story under each Feature to achieve the KPI finally required into the Dashboard
- For accomplishing ETL activities and to develop the KPI into the Dashboard, Developers in the Scrum Team to create multiple Technical/Spike User Stories.
This process to repeat for each User Story and Feature.
Sprint Goal: Scrum Team will collaborate and discuss what would we want to achieve in each sprint and decide.
Sprint Outcome need not be a completed KPI in the dashboard but, rather it depends on what the team wanted to achieve in the sprint keeping the larger goal in mind. However, the team should try to bring out give some value in each sprint by giving shape and meat to each KPI progressively.
Please let me know your thoughts and any of your perception will definitely help.
- We need to breakdown the requirements in BRD into Epics, Features, User Stories
- Apply Agile methodology for successful Implementation
If requirements are understood well enough to capture them in a BRD for breakdown and implementation, what agility is needed? It doesn't sound as though you have much need for backlogs, validation, or emergence.
My opinion is that if you do your suggested solution to ask #2, you won't need your solution to ask #1. It would be wasted effort to break things down into BRDs, etc if the team is going to do their own work. What you are describing is a method of refining the work. In my experience, you might be better off to let the teams take a portion of the work and start building it in a Sprint rather than use entire Sprints to perform spikes to investigate. Start building something, discover work as you go and adapt. Deliver increments of value so that you can get stakeholder feedback and adjust as you go. That is where Scrum is most valuable.
The way you have explained it, you aren't using the Scrum framework as it is intended. You are trying to fit some old project management practices (BRDs, requirements, time lines, etc) into something where you are using some Scrum terminology. And it isn't exactly agile either because you haven't described how you will be using new information gathered during your work to adapt your work and deliverables.