Does my Agile Look Fat in this Jira ?

Skoosh builds and runs a software product  that  manages professional athlete development for clients that include NRL, NZ Rugby and Cricket Australia. Skoosh is a small company of 3 people, 2 owners and an assistant. 

Skoosh was experiencing a situation faced by many small companies. As their client base grew, their existing processes struggled to scale effectively. In particular their customer support and software delivery practises needed improvement. 

Skoosh approached Pantheras for the purpose of identifying ways of working more effectively. They were currently using Jira and wanted to create a process that provided  greater transparency on feature progress. As experts of agile consulting in Sydney, Pantheras was happy to help.

In addition, the hope was that by formalising a process for client feature requests, Skoosh could gain benefits in efficiency, freeing up time to focus on other key initiatives. 

Pantheras - Agile Process Experts 

Scale-Ups must be able to take advantage of the ability to adapt and respond to market demand. Having processes that enable transparency without burdening people with additional processes keeps their agility whilst developing structures that enable visibility. 

Pantheras recommended the following approach: 

1. A discovery workshop to identify the support issue lifecycle and better understand the client context 
2. Develop a customer support process from the discovery workshop
3. Implement the customer support process using Jira as a method of tracking progress

By using Jira and agile practises to manage the rollout of the customer support process, Skoosh gained hands-on experience on how to hold requirements workshops, and adopt agile practises. 

Customer Support Discovery Workshop 

Requirements gathering can be an overwhelming task.  Where to start? What's the right level of detail? Will implementation affect requirements? A structured but flexible approach is needed. To give context, Skoosh started with an overview of who their clients are and how client’s use the system.

For structure we started with the support issue data to be collected and then what is the lifecycle of a support issue. Each lifecycle stage was called an Epic and stories were completed to deliver that epic. The support issue lifecycle discussion needed a more flexible approach as we solved the problem of different life cycles for different support issue types (eg Bugs vs Feature Request). The right level of detail included mandatory and optional fields and field mapping to Jira.

During our agile consulting in Sydney, we asked Skoosh to develop wireframes to check how implementation might affect the information needed and the way it was we collected. This created a valuable discussion that led to a better user experience and improved data quality. 

Story Mapping 

Story mapping was used to ensure adequate coverage. We used a simple naming convention to connect epics to stories. 

A number of stories were finalised that were mapped to each lifecycle stage so we could see the complete support ticket lifecycle. Testing Times delivered stories which required process only development.

Scrum Coaching - Are We On Track?

With Agile methodology now 20 years old, it seems like everyone knows how to do Agile - but how do you know if your team is getting the benefit? Are the Agile ceremonies providing value?

Skoosh had been using an Agile approach for many years and using Jira for almost a year and asked “are we using it right?”. Testing Times asked a number of questions about what does ‘right’ look like. The answer? - are we going to make the next release date?

The Skoosh Jira had been set up to focus on clients and it was difficult to see if work across clients was ‘on track’ for a particular release. We created new epics for  releases, support tasks and feature requests. This delineated and prioritised the work and we agreed on different column definitions depending on the epic. For example “Feature Requests” at “Client Review” meant something different to ”issues in a Release” at “Client Review”. Issues were linked to clients as that data remained essential.

Through focused facilitation stand- ups became a useful too that:

• Reviewed the status of each issue - was this right?
• Confirmed the action to advance the issue and its owner.
• Confirmed the ETA for issues in the next release  - if not what was needed so it would make the next release?
• Minimised discussion on issues that were for subsequent releases. 
• Looked over the current release, support work and new feature analysis and asked was the developers time spread too thin? - did priority calls need to be made?

When running stand-ups, the reasons for asking a question or suggesting a process were made clear so that the Skoosh team understood the Why? of good stand up facilitation. With the issues in the next release now all in one place and discussed at each stand-up it was easy to know “are we going to make the next release?”

As experienced professionals in agile consulting in Sydney, we left Skoosh with the ability to run their own stand-ups (they were quick learners) and with the confidence that their scrum practice was delivering on its promise.

This was a short project and a future engagement with Skoosh would include regular retrospectives that would embed a continuous learning culture.

Conclusion 

Contact us now to get the results you need from your agile practice and for process improvement.

Phone: 1300 291 191

eMail: enquiry@pantheras.io