Adapting JIRA PM tools for Gravitywell

At Gravitywell, no two projects are ever exactly the same. One week we can have every member of the team working on something different for as many clients as we have people and the next we can all be banding together to complete a single app. Just like we did on our recent Hackathon. This means that our project management style has to be as varied as our clients and tools.

We have a history of using a wide range of PM tools and each comes with its own advantages and disadvantages. To date we’ve used: 

Trello

• Great for: building simple, shareable boards, project specs that are likely to grow and change relatively quickly.
• Not so great for: keeping track of a large number of issues, seeing the overall progress of a project

 

 Zendesk

• Great for: managing ad-hoc issue and small feature / improvement requests across the whole team
• Not so great for: overall project planning, long-term blocks of development

 

TeamGantt

• Great for: long-term planning, clearly demonstrating resource-allocation to clients
• Not so great for: projects with a lot of unknowns, changing specifications

 

JIRA (SCRUM sprint setup)

• Great for: flexible projects with lots of team members, detailed reporting, balancing deadlines with specifications
• Not so great for: small projects, managing ad-hoc work

 

Google Docs

 

• Great for: quick lists, team discussion
• Not so great for: anything more detailed than a bulleted list, changes can be lost if not tracked

 

We’ve been managing more and more projects recently with JIRA’s SCRUM methodology. The Agile approach largely works for us, albeit with some adaptations as we still operate under an agency model. That means we tend to stick to clear completion dates and resource budgets. This works really well for our larger clients as it gives us a single point of focus for project management. The majority of our planning, discussion, and work tracking takes place within the JIRA board and its backlog. We ran into problems, however, when we tried to apply the same approach to Gaku.

With only a week to start and finish the app, we needed a way to keep on top of the project without the management side of things eating up all of our time. At first, setting up a week-long sprint in JIRA made perfect sense. We already had a clear set of deliverables thanks to Jack and Simon’s prep work and we were all used breaking down and prioritising stories as part of our usual sprint planning process. Halfway into the first day, however, we realised that this wasn’t going to work.

JIRA is powerful - overwhelmingly so. It’s very easy to spend an entire day building boards, configuring workflows, managing assignments, and adding myriad labels to better define every task. With Gaku, we needed to get into development as quickly as possible, without worrying about estimation or more detailed organisation. In this way, JIRA actively worked against us, hindering our ability to quickly prioritise stories by floating stories with subtasks to the top of the board. By the afternoon, we realised as well that we weren’t able to identify immediate bottlenecks quickly enough, leaving some devs stranded while others raced ahead on other tasks.

In need of a quick to set up alternative, we moved over to a shared Google Doc, adding assignments to bullet points and striking through tasks once they were completed. It wasn’t perfect but it was much easier to manage and keep up to date thanks to how much simpler it was. Still, we were forced to rely on more frequent huddles to identify and manage issues and let others know if we were blocked by other work.

Now that the hackathon is over, our hangovers have subsided, and Gaku is an ongoing project, we needed something in between the all-encompassing power of JIRA and a more basic todo list. Based on our wrap-up talks, we had some clear requirements.

Our ideal tool needed to have:

• The ability to build up a backlog of tasks to be allocated when we had resource available
• A clear overview of work in progress and time taken to help identify bottlenecks
• Separation of bugs, new features, enhancements, and more generic work (i.e. devops, project management)
• Visual separation of working domains to help track tasks. Gaku is made up of three distinct parts - the mobile client app, the web-based instructor dashboard, and the API that manages data for the both of them
• Flexible delivery timeline - no strict sprints as we’ll be picking up Gaku work in gaps between other client projects

So, what did we end up using? JIRA! In recent redesigns, the platform has expanded and made it easier for smaller projects to fit into its framework. Ironically, this simplicity comes with a lot more preparation before work can begin but, once completed, it’s largely set-and-forget.

In a nutshell, we’ve moved away from the SCRUM-based sprints and swimlanes and opted for a set of smaller Kanban boards, one per part of the Gaku suite, all drawing from a single backlog of jobs. Prioritisation is done by placing one story above another and can be updated at any time. There are no subtasks but the stories themselves are more granular.

We have:

• Bugs - for things that aren’t working correctly
• Features - for things we don’t yet have in Gaku
• Improvements - for things that aren’t broken but to need adjusting or expanding
• Tasks - for non-development jobs

This gives us the granularity we need without needing to crowd single stories with subtasks or try to remember that one item is the responsibility of more than one person. To help identify bottlenecks and prevent people from getting swamped with tasks, we’ve also added a limitation of in-progress 12 tickets per board. This figure will likely change over time, depending on how many people are on the project at once and what our typical pace ends up being, but it gives us a ceiling that prevents new issues from coming in until work that was there first is cleared off the board.

Deadlines are far more fluid as well. Rather than specify delivery dates, ongoing development can happen until it’s deemed the right time to launch a new batch of features. All of the work that’s ready to go is then collected under a release name / number and cleared out of the system, wiping the slate clean until we’re ready to start up again on the next set of tasks.

All of this makes for a cleaner, easier to navigate worklog that developers and project managers can understand at a glance and manage without having to juggle too many things at once.