AgileBI Requirements Workflow
As a BI Practitioner
I want to understand what order to gatther requirements
So that I can gather them efficiently
When coaching or mentoring a new AgileBI team on the AgileBI Way one of the first things they ask is what is the standard order in which to gather requirements? Do we run BEAM workshops first or do we run the Information Product workshops?
There is no standard answer.
One of the awesome things about the AgileBI Way is you can use a lot of the techniques in any order you want. You can effectively create your own AgileBI Way using these techniques as building blocks (I tend to think of them as Lego blocks) and combine them to create your own workflow (I tend to think of my own Lego tower).
AgileBI Requirements Techniques
There are a core number of AgileBI techniques that you can use to create your own workflows. Some come from the reqiurements view, some from the engineering view. These include:
- Vision and Scope, Stakeholder Onion
- Information Products
- Data Requirements (BEAM)
- Data Vault Modeling
- Business Rules
Each of these techniques have different processes for capturing the reqiured information and different templates to capture this information in. [thats what makes it cool]
Examples I have seen
Working with different teams across different customers I have seen different workflows emerge from each of them. Often this is driven by the type of project that is being delivered.
Legacy System Replacement
[reverse enginerr the legacvy platform][new data build first][content only]
New Data Build
[new thin slice]
Other requirement articles.
As a Developer
I want to understand how to capture content reqiurements quickly
So that I can estimate their size and obtain a priority for the order to deliver
As a Developer I want to understand how to document business rules So that we can increase the speed of delivery Another of the more difficult capabilities in data warehousing is the definition and...
One of the more challenging areas in Business Intellegence and Data Warehousing is understanding how to apply tests to data that has been transformed, to prove we have delivered a correct result. It can be as simple as proving that we are presenting the right revenue,...
With the death of the 100 page Business Intellgience strategy how do you get your stakeholders to come on the journey and agree to invest in the time for your AgileBI to create new data and content for them. With a waterfall project the process is well know, you do...
As a Developer I want to understand when and how to understand the source data So that I can be sure I can build the things in the users stories and as an input to the estimate of the effort required Often the majority of the AgileBI team are...
As a BI Practitioner I want to understand how to set expectations and limit the scope of a set of iterations So that I have some boundaries which means we will not have endless iterations or additions to requirements, without agreeing these changes upfront [[...
[[why you need to do it]] [[stakeholder onion]] [[surprise stakeholders and their new requirements]] [[identifying who should be keep informed]]