Works
Works

Logistics App Discovery

Recently we were approached by an entrepreneur to build a system that connects transportation vehicles to the renters. It is similar to Uber for logistic vehicles like mini vans, small and medium trucks. We were quite excited as this is going to be a green field app and we were getting involved in the early stages of building this platform. We also have full freedom to choose the right technology stack. A dream come true for software consultants.

I would like to share our experience in what we did to chart down the scope of work and how we worked together, what should be the scope of the Minimum Viable Product (MVP). We also busted some assumptions made by the business in the process. Tag along for a trip down our memory lane. I am sure you will learn a thing or two.

Engagement Model

Our client, the entrepreneur is also our business owner. As this whole idea is nascent in his mind, He has not yet built an operations team. So, our plan was to spend 5 days, approximately 6 hours a day with him to understand the problem space and arrive at a solution that takes into account all his constraints.

Requirements Elicitation

Since this is a domain were we don't have any business experts, Our google skills and our client's expertise were our starting points. Having someone who worked already in this domain is ideal. But reality is not always ideal.

Our initial discussion was to understand the 'Mission Statement' of the business and its big picture. It went more like a disucssion than a monolog from our client and we felt a lot more connected after this exercise. Next, we discussed how a normal day in this business would look to identify the personas involved and listed them down.

With Personas and the mission statement, we are set to dig down deeper to build the user flows. That was a fun exercise as we went back and fourth on already built flows based on the new insights and understanding as our discussions intensified. As we were building these user flows, we started creating low fidelity screens to visualise how it will feel. And this step helped us greatly as we were able to get to all the nitty gritty details of how things will fall in place.

For example, In the vehicle renter flow, we wanted to keep it easy and simple for the user to book a vehicle. For that, we thought of asking the from and to locations using google maps (duh!). But, We later realised that the operations team flow is very different between inter-city and intra-city bookings and it restricted the options we could show for the user when booking the vehicle. So, we revisited the renter flow and asked the user explicitly to select inter-city or intra-city option along with other details.

You could think this could be automatically derived using the from and to locations. But, what the operations considers inter / intra was not clear, dependent on the location and sometimes intra-city is not available for them based on their starting location as this will be rolled out in stages. So making a not so ideal UX change helped us save the effort of building a complex decision tree to derive it and instead had time to build other parts of the system.

We continued to do the same till we had around 30 - 40 screens that lists down all the user flows for different personas like Operators, Truck Owners, Fleet Owners, Franchisee and Consignor.

Epics and Stories

Since we got a very good idea of how the app flows would work in the form of interactive low-fi screen designs, We started creating high level epics to identify different features that needs to be built. Examples could be Consigner Management, Consigner Signup, Order Management, etc,. Overall, we created around 15 epics.

Then we started breaking down the epics into smaller functional stories. As we did this exercise we found the missing links that connect the different epics and started creating more stories. We followed the INVEST principle of creating a good story and at the end of this exercise we had around 50 story cards. This gave a very good picture of what it takes to build such an app. A point to note is, even after this much of detailed analysis and break down, my past experience has taught me that we will still have surprises during development. But, such a rigorous process of creating story cards will definitely reduce such instances.

Tech Stack Decisions

Since we know what kind of app we are going to build, it was quite easy for us to decide what could be the ideal tech stack for it. We based our decision on the following things:

  • How easy it is for the startup to hire developers once the development is complete. Even though we love to pick cool languages like Elixir or GoLang, it might not be a good choice for the business as they have to build a team to maintain and evolve it
  • Language / framework fitment. How easy (less effort) it is to build an app with the selected language and framework. How much of support we will get in the form of libraries and the community
  • What does our developers know and are comfortable with. Given almost all of the developers in TarkaLabs are full stack and are polyglot, this is not much of an issue as long as we don't consider their availability into account

Estimation and Planning

To find out what it costs to build it, We have to know how much effort it takes and the best way to find it is to estimate the individual stories (which are smaller and easier to guess) and add them up to arrive at the total. Then it is pretty straight forward to convert it to cost by multiplying our billing rates. Also, we don't do fixed bid projects.

We started with estimating the tickets using T-shirt sizes S , M and L. When we encountered a story card that felt bigger than L, we broke them down in smaller cards and estimated them independently. Yes, it was pretty rigorous exercise as couple of developers (who know the chosen tech stack) discuss and sometimes argue (friendly of course) and arrives at a number (an alphabet in this case).

After sizing the stories, we started sequencing them. This step is very important in identifying the number of parallel development streams that could build the solution. The sequencing will also take into account the iterations at which different stories could start work. Here is how the board looked after this exercise:

To arrive at the approximate time it takes, we had to transform the T-shirt sizes to approximate days. Here also, we took into consideration the kind of developer (experience in the tech stack, seniority, etc) who will work on this project. Note that these are the approximations and usually they average out.

S = 1 - 2 days
M = 3 - 5 days
L = 5 - 7 days

With this scale, we calculated the days (min and max) needed to complete every iteration and when any one iteration is heavy, some of the cards were moved to the next iteration. We repeated this for all the iterations. Then, by adding all the min and max days across the iterations, we found out the range for the whole MVP which came to around 97 - 162 working days.

Arriving at the cost is as easy as multiplying this range with our billing rates. And our client as expected, started asking if we could get it any lower. And our answer was an immediate yes, Remove the cards from the board that you think are not that important, the cost will automatically come down. He immediately understood the dynamics and started making sure every feature on the board is absolutely necessary or can be shelved for future releases.

Summary

Overall we and the client had a very good engagement and he went home happy as the product he envisioned is way lot clearer in his mind now, we know what we are getting into and are more confident of meeting the expectations in terms of cost, quality and scope of work. It is a win win for all.

Members
Vagmi, Sudhakar, Vinoth, Sharavanan
Technologies Used