How to scope, plan, and track development in Fibery

Product company 🚀

11-50 ppl 🎩

Healthcare Software 👻

Switched from Jira, Trello 😎

Templates used in this customer story

Software Development Product Management Retrospectives

My name is Emanuele Tonello and I am the Head of Technology at Conpago. Our digital care management system is a cloud-based platform that brings care providers’ communication, customer support, rostering, virtual service delivery, and other business administration together in one place.

On a more practical level, what we are trying to do is to revolutionise the aged care industry in Australia by bringing transparency, efficiency, and ultimately better care through a digital platform, where older people can be supported more effectively and the organisations can focus more on the care versus admin or other time-wasters.

What do you use Fibery for?

We use Fibery to run every aspect of the tech team work, and also to capture all the features and product decisions. It has been very helpful for tracking hires as well and I am working closely with the team to capture more and more aspects of every business process that we can.

Why did you switch to Fibery and what tools did it replace?

I was totally captured by the way Fibery provides the tools to an organisation to build its own process, instead of prescribing a certain way of doing things. For us, it replaced Jira and Trello which we used at different times with varying levels of success. We also aim to replace Salesforce when Fibery can send emails.

Now spill the tea: How does your Software Development process look like?

How do you scope & plan development?

We run a very lean Kanban process where we simply have separate Boards for each domain (Backend and Frontend) and we add bugs and improvements as we go. All the stories and improvements that we are not going to work on right away are created in the Planned state. After every major release we do a retrospective to analyse what we did right and what we did wrong and then subsequently plan the next batch of features and tasks to work on. This allows the flexibility to not be bogged down by too much unnecessary process, as we're currently at the stage of trying to increase velocity and scale the product.

The planning part is also aided by the Ideation and Roadmapping spaces. We respectively run the first part of the product process in Ideation by putting together all the different ideas and feature requests and trying to score them to prioritise them. We always examine the counterpoints to make sure that we are critical of everything we are planning to introduce. In the Roadmapping space, we store all the Features with their respective documentation. Here we try to go into as much detail as we can to remove the guesswork for the developers and also to help the business understand how we want to solve the problem at hand.

How do you track and analyze progress?

We have 3 separate boards for the different domains of the platform that we are working on (Responsive app, Dashboard and Back end). On them we track the different statuses which also include the interaction with our testers. We only track cycle time at this stage.

How do you store a development wiki?

We store our development documentation in a folder in the Software Development space. This allows us to have all the dedicated information available to the team to view at any time and go back to when they need. We use only docs and not whiteboards at this point.

How do you run retrospectives?

We run retrospective after major app releases (with a group of key team members). We track what we did right, what we did wrong and what we learned. Out of it, we log Action Items for the management to enact.

Praise time: What is your favorite Fibery feature and why?

The flexibility is outstanding. Just being able to track or add any field or relation at a moment's notice has been amazing, especially in terms of capturing fleeting ideas and feedback on the fly.

Criticism time: What you don't like/lack in Fibery?

It’s been challenging for me to onboard non-technical personnel onto Fibery. Not for lack of documentation or help material (quite the opposite, we are looking to replicate Fibery’s knowledge base in our own product), but because they developed a perception that it was difficult to learn and master. Maybe the complete flexibility seems overwhelming. I am not sure if it was because of the type of language when I explained or if I needed to run more dedicated sit-downs to show and tell how it can be used, but internal adoption has certainly been challenging.