Try it now
CASE STUDY

FinTech Startup: Improved Delivery From Sprint To Sprint

Project delivery: missed deadlines

You’ve probably also come across a situation where you have everything you need to implement a project. However, you fail to deliver quality and timely software deliveries from sprint to sprint. Here’s a story of my client.

I was approached by a client who received investment for his startup, but could not launch it on time.

Previously, when developing software products, our client relied on generally accepted approaches to assessing and conducting development, following the recommendations and experience of companies that had a good background and successful projects. As practice has shown, you can learn from someone else’s experience, but it is not always applicable in your situation.

9AM - 6PM

Monday – Friday

Get a Quote
Copy of Development control

About the Client

Our customer is a startup from United Kingdom who received investments from a private fund to implement a online payment service. The application must include an electronic wallet, pier-to-pier transfers, cashless payments for partner services (taxi). The application also has functionality for managing personal finances.

Analysis and action plan

As a result, the client received a picture (see sprint 11), with the failure of internal deadlines and failure to fulfill the intended functionality. And this situation was repeated from sprint to sprint! It became clear that it was necessary to change the approach.

After analyzing, based on the experience of previous projects, we came to the conclusion that it is necessary to develop an individual process management system, monitoring these processes, analysis and a system that will provide the client with effective software production. It is important to understand that by introducing one thing, you will not get the desired result! Only by comprehensively approaching the adjustment of the entire process can you significantly improve the performance indicators of teams.

If we look at the graphs above and compare sprint 11, which was before the implementation of our system, and sprint 20, where the system has already been implemented, we will see that the team’s productivity has increased almost 3 times!

At the same time, the approach to planning and evaluating tasks has also changed. In sprint 11, we see a plan of 256 story points, and in sprint 20 – 145.

We would like to emphasize that the implementation / compliance with some part of the methods will not provide the desired result! Only an integrated approach: building processes, setting up the collection of metrics, monitoring, analyzing, adjusting and working with a team on a daily basis will give you a visible effect.

Delivery process

What are the reasons for the delay in delivery?

  1. The planning was done superficially. The tasks were not sufficiently worked out. Tasks were taken to work without a proper description. As a result, many nuances arose during the implementation process. It happened that the backing was not ready for development, and a task was already set for the front.
  2. Misplaced priorities. Before performing the current task, it is necessary to implement other functionality.
  3. Each developer made task estimation and / or TechLead did not participate in the assessment of tasks. As a result, the assessment was not correct, each storypoint did not have the same value. If the assessment was in hours, then the developers did not include communication, risks, complexity in the assessment, they often overestimated their capabilities.
  4. The composition of the team is not optimal. The project often lacked testers and / or business analysts.
  5. Clarifying the requirements took a lot of the team’s time. The client collected an excessive number of meetings to discuss the approach to the task. The composition of the rally participants was excessive, much less participants were enough.
  6. Developers lost focus while completing a task. They were distracted by extraneous activities, started fixing bugs or refactoring code that had nothing to do with the current task. In case of difficulties in completing tasks, the developer would get stuck and wasted a lot of time.
  7. Tasks were not taken into testing on time. Bugs were fixed chaotically, there was no test documentation, it took a lot of time to “invent” a test script on the fly.
  8. Inconsistency of requirements. The additional time of the tester was spent looking for an approach to testing the problem.
  9. Tasks did not go through a full cycle (workflow), some statuses were skipped or did not change in a timely manner.

Request Audit Of Your Delivery Process

Send request
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google
Spotify
Consent to display content from Spotify
Sound Cloud
Consent to display content from Sound
Get in touch