The JIRA has been a powerful and useful tracking tool for most agile projects. It is being evolved to provide more convenient features onward. In past half year I and my team just worked on a TM1 project where we managed and tracked all requirements, tasks and efforts in JIRA tool between multiple teams.
TM1 is an IBM OLAP tool to build analytic model, cube and create reporting for financial account analysis and different cycle planning and forecasting. The regular way to drive this kind of project is to do requirement gathering via proof of concept, architecture, build, unit test & deployment etc. During that process the major tasks might be managed and tracked in tool such as MS project or excel to follow a traditional approach. Since we are the agile advocator, we would love to maximize the value of agile particularly scrum in the daily work. We did not have explicit experience of employing scrum in BI like TM1 project but this is a good endeavor for the TM1 team. In the following section, the challenge occurred in the project as well as some JIRA tips were summarized.
Challenge
The requirement is not clear in the beginning even after development effort is started. I believe this is common in most projects but we should handle it flexibly to reduce its impact on plan. Business analyst and project manager were assigned at client site to work with different team to identify customer’s future vision on their finance planning, also do investigation on legacy application. The typical unclear TM1 requirement may contain uncertain planning cycle, data feeding source, calculation rule, roll-up/drill-down requirement etc.
The requirement will likely to be changed and affect specific design. The requirement change here does not have to undergo the formal process and most likely it relates to point 1 above. There might have been great number of design documentation out there like dimension, attribute and cube. But the dimension name may be changed; the attribute and elements may be changed. A baseline of all objects specification should be settled and therefore all stakeholders can know what the design change is in the past, current and future state.
Measure the team effectiveness and area to improve. Usually a learning curve is a must for each member and the whole team. Some members are skillful in technology but they need to know about project input. Others may need to ramp up themselves further in skill set. The way to learn about team effectiveness in JIRA is to look at velocity in the chart. However we will need to do further analysis – is that caused by unclear requirement, or the technical competence? The challenge goes to how we can quickly identify the improve area for individual as well as the team in the agile tool.
Eliminate multiple-shore team’s miscommunications. Yep, the JIRA itself will function as a communication between teams. Even though, the miscommunication will still occur because
of insufficient task description and different understanding. In our case we have both onshore and offshore developer and we should put their focus differently.
I don’t think we can solve all the problems by a hit with hammer. But I do like to go over the JIRA user experience on making team to be more flexible, productive and manageable.
JIRA Tips
Establish lineage of requirement, design, task and testing evidence. This is effective way to track completed effort in different stage and actually it is necessary to keep everyone in the same page in understanding in delivery. Option 1 is to build link in the Jira between feature, task, test case and issue etc, JIRA provides bidirectional link along with type to bind each. Option 2 is to build parent child feature.
Feature to sub-feature. We opted this one as we have found that link is not explicit in presenting requirement change while parent-child feature is better. For instance, the customer account gets changed for many times. For initial one we create parent feature called customer account dimension and sub feature such as load elements, load attributes. Going forward, the dimension name change or element change can be deemed as a sub feature under that initial one.
Bulk import for all breakdown features. JIAR provides a way to import all features from csv/spreadsheet into your project. That is helpful to save time.
Embody review effort in JIRA. In our quality assurance model, typically we will conduct internal review, formal review. When a feature/sub-feature is completed, it must be assigned to lead developer for review. Reviewer can put his comment such as “Review Complete with First Pass” or “Review Complete with Reject” to proceed with next step. Therefore it is easy to report how many features are reviewed out of total and how many passed.
Build version hierarchy. The reason for this is to generate feature status at each sprint and scrum level. With version hierarchy, user can go to agile planning/task/chart board to gain plain overall progress.
Streamline the steps in workflow. Try to maintain a minimum steps that is really needed such as open, in progress, offshore review, onshore review, approved. Too many steps will definitely slow down the communication.
