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

Why document Information Products?

When starting an AgileBI project there is often a need to undertake a prioritisation 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 some sort if 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.

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:

  1. The business outcome or benefit that will be achieved by using the Information Product;
  2. The business questions that will be answered by using the content;
  3. The data-driven business processes that are required by the users;
  4. The audience (persona’s) that will use it;
  5. The visualisations that might be delivered;
  6. 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 tasks.

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:

Information Product Template

When to create or update an Information Product Template?

Like a lot of the artefacts we deliver in our AgilebI approach 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:

  1. Prioritisation
    The initial version of the Information Product template is created, with the minimal amount of detail required to allow prioritisation to be undertaken.  It can also enable the product roadmap/backlog to be created and an initial High-Level estimate fo effort for each Information product (in terms of number of sprints)
  2. Sprint Estimation
    The Information Product template is updated with more detail to enable it to be included in a sprint.  This is often done as part of the backlog refinement.  The aim is to ensure it can be delivered within the sprint (or a number of sprints) that is expected.
  3. 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.
  4. As Built
    The Information Product template is finally updated as an as-built document to confirm what the dev team delivered.

 

 

Other Blogs from this category.

Adding members to the Agile Team makes you go slower

  As a Stakeholder or Product Owner I want I want to understand if constantly adding Agile Team members is a good idea So that I can have a valid conversation with my Product Owner and Scrum Master Initially at least!   Velocity When building a new AgileBI delivery...

Standups should be open not closed

As a Stakeholder or Product Owner I want I want to understand who can attend a standup So that I can ensure we are following an Agile approach Standups One of the many key things in deliverying in an AgileBI way is the use of daily standups to...

The Danger of Pipelining and Time Slicing

As a BI Manager I want to understand the impact of pipelining the Agile teams workflow So that I know if it is an approach I wish to use Managing to complete an AgileBI build in three elapsed weeks is very very difficult. And by a build I mean from...

Benevolent Dictator

As a AgileBI Guru I want to understand what a Benevolent Dictator is So that I know when one is needed   The team have discussed it "to death" and are now constantly repeating the same arguements "around and around" More informaiton is neded to progress...

Remote Scrum Masters

As a Stakeholder or Product Owner
I want some examples of things that can fail in AgileBI
So that I know what to watch out for

%d bloggers like this: