Feeds:
Posts
Comments

Archive for November, 2011

In this third part of the series on agile dimensional modeling, I will talk about requirements gathering using user stories.

 

So what is a user story?

A user story is simply put a representation of business requirements. Ron Jeffries has defined a user story using the three C’s of user stories.

  • CardUser stories are written on cards (or post it notes) called story cards. The card has just enough text to identify the requirement and remember what the user story is. They are used for planning and notes will be added to capture priority and cost/estimation
  • ConversationThe requirement itself is communicated from the business to the data warehouse developer through conversation. This verbal exchange of thoughts, opinions and feelings is often considered the most important part of user stories
  • ConfirmationThis adds the acceptance tests, that document the details that can be used to determine when a story is complete. The business communicates how they will confirm that the story has been delivered

 

A story card for data warehousing can look like this
Story Card 01

 

Writing user stories

There is no fixed way to write a user story. A story can be informal or formal and in a practical manner range from physical index cards on paper to dedicated IT systems. How you (your business stakeholders) write user stories is not significant, whatever works for you is fine.

The size of a user story is not fixed, but in my experience a user story should

  • Be small enough to be completed in one day
  • Deliver some business value
  • Be demonstrable

The following is an example of a story card representing a user story, that clearly needs to broken into smaller stories

Story Card 02

The following shows a story card with details added to the bottom of the card

Story Card 03

A formal way of writing a user story can look like this

Story Card 04

 

User stories are written by the business

User stories represents business requirements. It is the responsibility of the business to prioritize user stories. User stories are prioritized based on the added business value. User stories are written in business language so that the business understand the stories.

The word business is used so many times in the previous paragraph, that it should be very clear who should write the user stories: the business.

 

Next steps

In the following posts I will introduce sprints, the data warehouse backlog and how to use prototyping as an efficient way to get from user stories to a confirmed dimensional model, using timeXtender as the rapid design and deployment tool.

 

References

If you want to know more about user stories, I can recommend the book User Stories Applied by Mike Cohn (ISBN 0321205685)

Read Full Post »

This post is part of the agile dimensional modeling series, that promotes the use of agile to speed up business value driven data warehouse development.

The importance of the why

The first and most important thing to understand is always the why. The what, when, how etc. does not make much sense, unless we know why we are doing whatever it is that we are doing. In business intelligence and data warehousing, the why should always be because it adds value to the business.

Everything we do is done because it adds business value and when we need to prioritize what to do when, it is prioritized based on what adds the most value to the business.

Requirements gathering

Once we understand that what we will be doing should always be business value driven, it should become obvious that we need to talk to the business, to learn what actually adds the most business value.

The primary purpose of business requirements gathering is to understand what the business is trying to accomplish. It is the most critical step in data warehousing, as this is when we learn through conversations with the business what we need to build for them to achieve the business goals.

With the agile approach I am promoting, requirements gathering is an ongoing process unlike most conventional project management methodologies. In a conventional approach requirements gathering is often seen as a (lengthy) one time step, that will determine what will be done in the next many months.

With todays volatile business environment, we simply cannot afford to effectively tell the business that “you are only allowed to come up with requirements every six months, because we have already decided what we are doing for the rest of this project”. The answer is to work in short iterations and build our data warehouses incrementally.

 

Conventional requirements gathering

I have never worked with any organization, that did not already have a handful of very urgent business requirements the moment I stepped through the door.

With a conventional approach to data warehousing, these low hanging fruits or easy wins as I call them, will not be implemented until they have been very structurally considered along with all other less and very less important requirements.

Sadly you will spend weeks or more likely months analyzing requirements across the entire enterprise, before it becomes clear that you should have done these easy wins before doing anything else – including the last few months of analyzing requirements.

I love the Kimball dimensional modeling approach and his way of incrementally building the data warehouse. It is the most robust and scalable model for data warehousing. In my opinion the requirements gathering phase of the Kimball lifecycle is the biggest weakness, as it results in a very slow implementation of at least the first increment.

 

Incremental requirements gathering

What we should be doing, and what is fortunately being done more and more, is using some of the key elements from agile methodologies like SCRUM and XP.

As you will learn from subsequent posts, I highly recommend using user stories to capture business requirements. User stories are written by the business itself, thus you as an organization can easily capture new requirements concurrently with building a data warehouse increment.

User stories will be prioritized by business value and the data warehouse built in time-boxed increments of 1-2 weeks duration called sprints. As the business requirements that goes into a sprint is decided before every sprint, it is a very good way to ensure that you will constantly consider what makes the most value to the business right now.

User stories are placeholders for business requirements and contain just enough text to serve as planning and to remember what the story is about. With this approach you do not have to spend a lot of time with detailed analysis of the requirements, until the business decides that is now one of the current priorities for an upcoming sprint.

 

Next step

The next post will introduce user stories as a way to capture business requirements.

Read Full Post »

As explained in the How To Export A timeXtender Project, it is possible to export a project definition (the meta data) into a XML file. This would not be very useful, unless it can be imported again :-)

The following explains how to import a project definition from a file

How to import a project

  1. Click the timeXtender ribbon menu icon in the upper left corner
  2. Select the Import/Export menu option
  3. Select the Import Project… menu option
  4. In the dialog that open, click the ellipsis button
  5. Select a file and click the Open button
  6. Click the OK button to start the import

Project Import Dialog

 

A note on version control

The project that is persisted in a file contains a single version of the project.

Every project is assigned a unique id when it is created (a global unique identifier, or in short a guid). During import this id is compared to existing project in the repository and if a project with the same id exists, you will see the following prompt

Project Import Dialog II

Save project as latest version

This will save the imported project definition into the repository, essentially “overwriting” the existing project as the latest version of this project.

 

Save project as a new project

Consider this like a save as function, that allows you to save a copy of the imported project with a new name and id, side by side with the original project in the same repository

Next you will be see the following prompt

Project Import Dialog III

Then you will be asked to specify a new name for the imported project

Project Import Dialog IV

 

The connection manager

Following a successful import, a prompt will ask if you want to run the connection manager. This provides a wizard style interface to set up all connections on the imported project

Project Import Dialog V

Read Full Post »

In timeXtender there is a feature called multiple environments, that automates the process of deploying project definitions between environments such as from development to test or from test to production.

If you ever need to manually copy or move a project definition between environments, the import and export features can be used.

The following is a very short guide that shows how to export a project.

How to export a project

  1. Click the timeXtender ribbon menu icon in the upper left corner
  2. Select the Import/Export menu option
  3. Select the Export Project… menu option
  4. In the dialog that opens, specify a location and name for the file
  5. Click the OK button

The export file is created in XML format, thus it is recommended to use a .xml file extension.

Project Export Dialog

 

A note on version control

The export function will persist the project “as is” in memory to the file system, thus the file will not contain any history about previous versions of the project.

Read Full Post »

%d bloggers like this: