T-SQL Tuesday: A Day in the Life of a BI Developer
Tuesday, July 17, 2012
by jsalvo
My name is Jennifer and I am a Business Intelligence developer at Trek Bicycles. I’ve been a BI developer for a little over a year and work with the Microsoft BI tools: SSIS, SSAS and SSRS. The BI team at Trek consists of 4 analysts (2 in US, 1 in UK, and 1 in Australia), 3 developers, 1 SharePoint developer/admin and 1 DBA. We use an agile process to coordinate development and DBA work.
The agile development process is broken up into sprints. At Trek we have two week sprints that always start on a Wednesday with a sprint planning meeting. On July 10th, we held our bi-weekly planning meeting as the start of sprint 69.
The planning meeting begins with a sprint retrospective. During the retrospective, each team member (developers and analysts) discusses what they felt went well and what didn’t go well during the previous sprint. We also discuss opportunities for improvement. This portion of the meeting generally takes 20-30 minutes.
After the retrospective, we then review all the stories queued up for this sprint. This generally takes 2-3 hours depending on the number of stories. At Trek, a story is a unit of work or development task. Each story includes a description of the request from the end-user’s perspective and a list of acceptance criteria. Here’s an example:
As an Accounts Payable stakeholder, I want a consolidated source I can use to examine all of the vendors maintained in the Accounts Payable systems so I can manage vendors more effectively.
Acceptance Criteria:
- Vendors from (list of transactional source systems) exist in (the mart) according to the specifications in the AP Cube Bus Matrix.
- The values associated to the attributes listed in the bus matrix are derived according to the tables, fields, and rules listed in attached document.
- The ETL is scheduled to refresh vendor data once a day.
As a team we review and discuss each story and then each person individually scores the story based on perceived complexity (we use http://www.planningpoker.com/ to do our scoring). At Trek, valid scores are: 1, 2, 3, 5, 8, 11, and 13 (Fibonacci plus 11). Once each person has submitted their score, the scrum master decides what score to assign to the story (usually the average of the team members’ individual scores).
Once we finish scoring the BI developer stories, we proceed to review the SharePoint and DBA stories. We do not score these stories as a team, instead we allow the SharePoint admin and DBA to assign their own scores to the stories. The SharePoint admin and DBAs time is divided between sprint and administrative work; therefore, they generally do not have as many stories each sprint as the BI developers do.
Once all the stories are scored, we review each team members velocity from the prior sprints and assign a velocity to each developer, SharePoint admin and DBA for the new sprint. Velocity is basically the number of points each developer / admin is able to complete in an average sprint.
The meeting completes around lunch time and after lunch we select one or two stories to start working on during the remainder of the day.
