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
Why document Information Products?
When starting an AgileBI project there is often a need to undertake a scope, size and prioritise phase before you can start the delivery phase.
If you are running a waterfall / Agile hybrid process, then you may need to do a project initiation or business case phase before you can start the delivery phase and for this, you need an estimate of the time it will take to deliver the “total” solution.
As part of this, you often have to do an estimate of the resources required to deliver or agree on the order in which you will deliver. The old “give me a dedicated team and 12 months and I’ll deliver your hearts desire” trust me approach is not so successful sometimes.
Of course, we don’t want to do Big Requirements Upfront. The challenge is how do you do enough work up front to be able to give confidence you can deliver but not spend months stocktaking the current environment or gathering masses of detailed requirements that will change before you start delivering.
One of the ways to do this is to create an Information Product Roadmap to articulate what might be delivered, and when, during the delivery phase. This gives confidence you have done enough work to have a high-level prioritisation and estimate of effort, and that you understand enough about the requirements to have some focus when you start building.
And once you start the delivery work, how do you get just enough requirements to develop in an iterative way, where change is ok because you haven’t spent a long time capturing and building to those requirements.
The AgileBI technique we use to manage these challenges is documenting requirements in an Information Product Template.
What is an Information Product?
To do this we use the concept of an Information Product. Information Products are a way of describing something that bounds together:
- The business outcome or benefit that will be achieved by using the Information Product;
- The business questions that will be answered by using the content;
- The data-driven business processes that are required by the users;
- The audience (persona’s) that will use it;
- The visualisations that might be delivered;
- The features the users will require.
Each of these are defined the way we define them in the delivery phase using our AgileBI techniques such as BEAM, Story boards and wireframes.
I often think of Information Products as apps on your smartphone, something you click on to achieve a task or outcome.
Where can I find an Information Product Template?
The Business Intelligence Information Product Template I use to define an Information Product can be found here:
When to create or update an Information Product Template?
Like a lot of the artefacts, we deliver in our AgileBI Way the Information Product template is updated multiple times as we progress through the process. Each time more detail is added to the template as we discover and document it.
There are four major stages where the Information Product template is updated:
- Gather, Size & Prioritise
The initial version of the Information Product template is created, with the minimal amount of detail required. This allows a high-level estimate of effort to build the Information Products to be t-shirt sized and the Information Products to be prioritised. The gathering, sizing and prioritising enables the Information Product roadmap/backlog to be created.
- Backlog Refinement
The Information Product template is updated with more detail to enable it to be sized using story points during the backlog refinement. The aim is to ensure it can be delivered within the timeframe that is expected.
- Build Design
The Information Product template is updated with enough detail to enable the dev team to start building. This is typically done at the beginning of the sprint process, in conjunction with the Vision, BEAM and wireframing workshops.
- As Built
The Information Product template is finally updated as an as-built document to confirm what the dev team delivered.
Other requirement articles.
As a Developer I want to understand how to run the Information Products workshops So that I can deliver reqiurements quickly Information Products As outlined in the Information Product post there are four major stages where the Information Product template is...
As a BI PractitionerI want to understand what order to gatther requirementsSo that I can gather them efficientlyWhen 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...
As a product owner I want I want to understand how to identify my stakeholders So that I know who can tell me what to do and who to tell what we are doing Other Blogs from this category
As a developer I want I want to understand how to use wireframing to confirm requirements So that I can build the right thing Wireframing is a technique we use to confirm two things: How does the user wish to see the content presented? Have we identified...
As a scrum master I want I want to understand how to make retrospectives fun So that I can keep the sprint team engaged The Data Requirements Gap There are two typical challenges when we gather data requirements. First, we capture and document the requirements in a...
When do BI projects that require new data we know anecdotally that once we have acquired the required data from the System of Records the majority of our time and risk is applying code that transforms and/or augments data. In my terminology I call this "doing bad...
As a BI ManagerI want to understand what risk and challenges I will encounterSo that I know what I am getting myself into Reducing your delivery timeframe down to 3 weeks, means you need to find ways to automate many of the...