How to make your customers happy? This topic is a frequent guest on a variety of meetups, conferences, and different business literature. However, at Etheric, we especially love the idea to be fair and transparent to our clients. This is the main reason why we've decided to publish a series of short talks describing how we work with our customers, turning their ideas into reality, and guard them against the risks of failing.

"Hey, isn't it just another guide on how to do Scrum?" you can think while reading the article. The answer is, "Yes and no." We definitely love the idea of Scrum, and we have built our project management processes on top of it. Instead, we try to answer the two following questions: "What can a customer expect working with us?" and "Why we find this approach useful for everyone?"

Internally, we split every project into 3 phases: initial planning, design, and development (no, we didn't forget about testing and maintenance). There is no handoff phase because, as you will soon see, we release often and the progress is visible very soon. Having this workflow helps us deliver products to the market faster. The first article in the series focuses on the project planning phase, together with the payment model description.

Planning

After the client has shown interest in working with us and agreed to do the first planning phase — we schedule a call with them to discuss the project. During this call, we ask them about the idea behind the project, how they see it, what is expected of it, and write a set of user stories based on the information they've given us. 

A user story is a high-level description of a journey a particular user takes when engaging with the product or service. These users are all possible uses of the final product - be it customers, internal users, or administrators. We try to write as much user stories as possible based on the client’s vision of the product and our domain knowledge, also including features planned far away in time. This is needed to have a clear picture of the product in the long term to adjust design and development right from the start. Now, that doesn’t mean that the user stories we write will not change. After we start working and analyzing the market, we gather valuable experience based on which we might add additional user stories, modify, and even remove existing, if they are no longer relevant.

A user story might look like this: “As a customer, I want to see a list of offers available to me, so that I can choose the most appropriate offer for me”. This sentence doesn’t describe technical or implementation details but gives an overview of a journey or feature the final product should have - a list of offers that are available to the user. Another user story might be focused on claiming the offer, or on admins adding offers to the system.

While writing a user story we also attempt to assign a number to it - an estimate of how much effort it will take to finish this particular story. This estimate is not in hours — absolute units, but in relative units called "story points". We use the Fibonacci sequence - 1, 2, 3, 5, 8, 13, 21, etc. — to estimate the story complexity or effort. What this means is that a user story with 5 points is easier and faster to do than a user story with 8 points. But please note that these estimates are just that — estimates. They might change during later phases based on our increased understanding of the product, the market, and the domain. Nevertheless, they give the client a general overview of how big the project is, how long it might take, and how much it can cost. (The pricing model is discussed in further sections)

These user stories form a list called the "backlog". Together with the client, we try to prioritize all of the user stories in the backlog based on their added value to the product. The goal is to select the user stories that will add the most value in the least amount of time. This is important to do, as we don't want to implement minor or nice-to-have features first, as they will not impact the customers or consumers of this product significantly at first. 

Then, having a prioritized backlog, along with the client, we pick a set of user stories starting from the top to form a so-called MVP - Minimal Viable Product. The number of user stories picked depends on the product itself, the client’s deadline, and budget. This set of user stories must amount to minimal, albeit functional product that must be usable and can be shipped to customers. Usually, the implementation of such user stories shouldn’t take longer than two or three months. It is important to deliver the MVP as soon as possible to gather user feedback and act on it right away. If the customers don't like the product, it is not gaining much traction, or the market conditions have changed - it's vital to pivot the direction the product is heading in order not to fail and deliver a great and successful service.