Agile Project Management has been a key methodology for increasing speed, collaboration, and ability to deliver a product. It is an iterative approach to managing projects that involve continuous releases and feedback from clients. Thanks to the advantages it offers, most of our development today employs the agile methodology.Before we switched to JIRA, our PHP team was using the traditional shared Excel-based approach to maintain backlogs. Excel is often simpler to use and does not involve a learning curve for all parties involved (including customers), thus making this the more convenient method of project management. Sprint tasks were tracked through Trello.However, Trello has its fair share of limitations when being used as a tool for sprint management:
- Bugs cannot be linked to a task and have to be created as a separate task.
- Dependencies between two tasks cannot be clearly defined due to a lack of relationships between tickets.
- Additionally, we could not measure complexity of tasks which is an essential part of our task estimation as it allows us to easily estimate complexity of future tasks of a similar nature.
In order to compensate for these shortcomings, we decided to shift to JIRA. The change, as occurs with any other change, was initially met with a lot of resistance. Some had apprehensions about the learning curve. Some are worried about the overhead. Besides, since Trello was working (though not without its disadvantages), there were the standard "If it ain't broken, why fix it?" objections, so we decided to make the transition as smooth as possible.
The process of Adoption of JIRA
When adopting JIRA, we used a standard workflow that was generally used for a team of 10+ users with biweekly sprints. Our customers would gain visibility to JIRA once we had established the process. However, our development team consisted of only 6 people. Additionally, our sprints were weekly and the client was apprehensive that shifting to a biweekly model might make the existing workflow too complex for our small team of 6 users. Hence, the first change we made was to simplify the workflow to meet our needs.We had set a deadline of four sprints to get the team used to JIRA and remove any burdens that the tool might bring into our sprints.The first sprint was created with just the hour-based estimations and focused on getting the team members used to the task of updating tickets and transitioning them through the defined workflow. Meanwhile, we also recreated our backlog in JIRA.On completion of the first sprint, we provided our end users access to JIRA. Since the backlog was in the ticket format, our daily huddle with the client became shorter since everyone was on the same page and tasks were prioritized and updated in real-time. Our internal scrums became shorter since everyone was aware of the status of each task and our JIRA tickets gave us a quick overview of any impediments or clarifications required for each task.Additionally, JIRA provided us a platform to plan a few sprints ahead. We would prioritize and analyze tasks for the next three sprints, giving us ample time to come with the potential impact of any changes that would be made to the system. The visibility it provided to the customer and to the development team made this process of prioritization easier.The tracking of QA defects on JIRA took some time. We hadn't shared Trello with our customers; there was some tentativeness towards exposing our bugs to them. However, with some shifts in temperament, our development teams began performing more thorough unit testing to reduce the number of bugs that would slip to QA. QA bug tracking on JIRA also allowed us to ensure that every bug was mapped to a task (past or current) and hence, enforced the resolution of all bugs before sending the changes to UAT.
Sprint Planning for weekly sprints through JIRA
The team that started using JIRA was performing ongoing enhancement of an application that had been launched a while back. This meant that in addition to the planned sprint task, quite often high priority tasks would be requested as well. These tasks could be related to year end reports, performance tuning, etc. Hence, we would plan for only 2.5 to 3 days of the weekly sprint. If there were no additional tasks requested for that week, we would then pull the next prioritized task from the following week and complete either only the development part or both coding and enhancement, depending on the team's available time and bandwidth.This allowed us to clearly map our client’s expectations for every week and often surpass expected deliverables without overworking our team. This, in turn, allowed our customers to set the right expectations with their customers (end clients) as well. The result? Happier customers, end clients, and developers.About Ideas2IT,Are you looking to build a great product or service? Do you foresee technical challenges? If you answered yes to the above questions, then you must talk to us. We are a world-class custom .NET development company. We take up projects that are in our area of expertise. We know what we are good at and more importantly what we are not. We carefully choose projects where we strongly believe that we can add value. And not just in engineering but also in terms of how well we understand the domain. Book a free consultation with us today. Let’s work together.
.png)
.png)
.webp)
