Teams that choose to take an agile approach to data warehousing will be faced with a planning meeting at beginning of each iteration. The goal of this meeting is pretty straight forward; plan the upcoming iteration. Accomplishing this task with an acceptable level of accuracy is not quite as simple. The prioritized backlog of user stories needs to be reviewed, development time estimated, and the team must agree on the current iteration’s deliverables.
Planning poker offers an enjoyable and very effective method for estimating backlog items. The process is pretty simple. Tasks are presented & described one at a time. After a brief discussion about the task, a vote is taken. Each team member votes on the effort required to complete the tasks. This is where the poker part comes in. Cards, apps, or scratch pieces of paper are used to record each person’s estimate until they are simultaneously revealed.
Pretty simple, right? There are some very good reasons for this method being so effective. First, nobody is going to influence another person’s opinion which is important for obvious reasons. Everyone is going to be fully engaged because votes that are high or low will need to explain and possibly persuade the other team members of their position. There is an element of crowdsourcing involved as well.
Effort estimates are cast using Fibonacci numbers. This seems like a minor point, but it takes into account the difficulty of estimating large portions of work. As Fibonacci number increase the spread between them also grows. It often makes sense to break user stories into smaller tasks. This keeps the effort estimates based on a piece of work that is much easier to consume. For BI/DW projects the list of task will usually include items such as:
Research data source
- Design target model
- Design data flow
- Develop ETL
- Deploy & load mart
- Modify cube
- Create reports
Planning poker also results in a very relevant way of tracking velocity. Each iteration results in a certain amount of effort completed. The sum of the work effort (based on planning poker) for each task completed becomes the current iteration’s velocity. As the project continues a series of completed iterations can be averaged to come up with a very good estimate of expected velocity in upcoming iterations. With an expected velocity known, figuring out which backlog items will be completed in the current iteration is a matter simple math.
BI/DW projects offer challenges to this planning process that should be considered. Some examples include the following. User acceptance and data validation are volatile tasks that involved business sponsors. Migrating assets to a production environment may also be impacted by influencers outside of the development team’s direct control. BI/DW projects also contain long chains of dependencies. If the method chosen to source a metric turns out to be in error, then it is also likely that a number of development tasks will be impacted impacting estimates. Planning poker may not resolve these risks, but it does help keep them top of mind which should result in every team member being very aware of the importance of quality work at each step in the process.
If you find yourself struggling to come up with accurate estimates of work effort, then give planning poker a try. It works great for agile BI/DW projects, and it turns a routine meeting into something that can actually be fun.
