What Stormotion's Project Management Flow Looks Like

To successfully deliver external and internal projects, development companies and teams surely need some sort of structure during the whole workflow. For this matter, they implement various Project Management concepts into regulating the development flow.

We decided that it’ll be quite useful to share how Stormotion approaches Project Management. So, if you’d like to learn more about our approach and find PM insights from an experienced development company — welcome!

Generally, our approach is based on PMBoK (Project Management Body of Knowledge) guidelines. We won’t talk about it in detail since it’s not essential to understand our approach — we’ll describe every step of our teams’ Project Management in detail.

As a development company, agility is something we need 99,9% of the time. For this purpose, we implement Agile Manifesto (a set of values for Agile Software Development) and Agile Triangle concepts into our workflow. The Agile Triangle takes value, quality, and constraints from a Classic Triangle (which are scope, cost, and schedule) as the main aspects that regulate PM flow.

Additionally, our team provides consulting services. Meaning that we help out Partners with Product Ownership (maximizing product value by defining activities that can help them achieve the desired outcome). Such activities can include:

• building product vision;
• defining, evaluating, prioritizing, and scheduling scope;.
• preparing roadmaps and reasonable version limitations.

Without further ado, let’s take a look at how we help our Partners generate product value at each development step and how we deliver high-quality solutions no matter what! 🚀

Tips & Tricks from Our Project Manager

Apart from the general structure that we follow, we have some special methods that we apply to improve the quality of the Project Management flow.

Firstly, one of the main concepts that we apply is Continous Delivery (CD). In Project Management, the CD is a way of building the end products and achieving tasks in short cycles. It allows us to shorten the feedback cycle and increase the product quality.

Another important thing we pay attention to is WIP (Work in Progress or Work in Process) limits. It’s basically the maximum amount of work that can be done within various workflows. It’s essential to be realistic regarding the number of tasks that can be done simultaneously.

Additionally, we make sure that the gained value during the development is never lost. For this matter, we implement Knowledge Management methods to structurally store and document the information we collect during each sprint. This way, we can always get back to it and reuse it when needed.

We have 2 types of time management:

• Report on hours spent during the last sprint. Customers get it after each sprint.
• Report on total hours spent on specific tasks from backlog.

We generate the first one by tracking working hours using Clockify or Active Collab. Apart from hours spent, the report also includes the sprint time and user stories. User stories are conditional statements of what a user might want/need to do in an app. For example, “As a first-time user, I want to sign up using Facebook”. It explains the needed features — in this case, it would be implementing the Facebook Login feature using Meta for Developers tools.

If you’d like to dig into the user stories topic, feel free to follow the link to our article where we cover all the detail in this regard:

To generate the second report, we need the first one because it works as a foundation for it. Its main purpose is to compare the total hours spent on each user story and compare them with the maximum estimates.

If we come close to exceeding the set budget, we immediately let the customer know to get approval to work further. If we don’t get it, we look for alternatives that satisfy both parties.

Task Control 📅

As the name says, this is the process where we keep track of all the tasks that we have to work on during each sprint. For task management, we use the Kanban board.

There are several statuses that a task can have:

We also follow the rule of not starting to work on a feature until it’s designed & approved. It helps us avoid expectations & vision mismatch.

Capacity Control 💻

To make sure that we’re up-to-date on our internal capacities, we use the TimeOff.Management System. This is where we request and approve vacation days, sick leaves, keep track of holidays, etc.

It allows the Project Manager to plan each sprint according to the availability of the employees. It’s important to set reasonable scopes of work and provide customers with realistic expectations regarding what we plan to accomplish.

Something we prefer to do is to never expect full availability of the developer for each sprint. Normally, it would be 80 hours (40 hours/week with a 2-week-sprint) but we assume 64 hours per person.

This is our way of implementing risk management methods into our work — it’s always better to complete more in a sprint than to set unrealistic expectations. Plus, they allow us to take time management deviations into account.

Quality Control 📝

For quality control, we create a document that’s called Master Test Plan. Generally, this document is created when we start working on the project and defines quality control rules. Surely, we update and adjust it later on during the development to make sure that it’s consistent with new challenges and values.

The content of the Master Test Plan usually includes:

• the expected quality of the product;
• a set of quality test methods for each feature;
• entry/exit conditions for Quality Assurance managers. For example, to enter the project, they need to have access to all test accounts and documentation. On the other hand, they can exit once they go through every quality checklist, verify necessary features and bugs, and no bugs have a severity level higher than minor.
• quality assurance risks. For example, no capacity, no access to the required resources, not enough input from various stakeholders, etc.

Something that might sound funny but actually makes a lot of sense — we try not to release on Friday. The reason for that is that there will likely be a certain problem after the release that we couldn’t predict even after several QA stages.

In case the release takes place on Friday, we'd have to urgently gather the team on weekend to fix it, which surely generates a lot of stress and overhours for both parties. Such challenges can happen and it’s normal for software development, but we try to decrease the chances of the occurrence as much as possible.

How We Manage Time Zone Differences

In this section, we’d like to talk about how we handle time zone differences.

To be honest, it’s the least worrying issue that we have in our practice. Since the software development industry has been highly internationalized for years now, we are 100% used to working with people from other time zones that are drastically different from ours. For example, while being based in Eastern Europe, we delivered products to our customers from the US and Australia.

Our team needed to deliver a workout app that pairs up with various exercise machines. After a thorough analysis of the scope of features that the client wanted, we found out that we can break one development flow into a few releases.

To be more specific, users could access statistics only after completing a full workout program (with a minimum duration of 8 weeks). We offered to postpone the implementation of the statistics tab, which includes multiple large-scale features, to the second release (8 weeks after the first one). Between releases, the tab itself would be covered with the “Coming soon” sign.

This way, the customer doesn’t lose any value since the statistics would be shown after completing the first program (which lasts 8 weeks) anyway. On the other hand, we would have enough time to deliver a high-quality product on time and within the deadlines that the customer wants.

Plus, the client can use the “Coming soon” sign as a marketing tool for warming up the users for the next release.

How to Help Your Tech Partners Deliver Projects?

A subsection we haven’t announced at the beginning of the section but still wanted to talk about — how you as a client can help us build your project faster without efficiency losses.

First of all, understanding the development team from the point of technical requirements is an extremely helpful thing that clients can do. Sometimes, it’s not possible to implement certain features before the app is prepared for it or before it’s actually needed.

For example, instead of implementing a certain feature that won’t be needed for the next few weeks, we can focus on making sure that the ones we release don’t generate more technical debt and don’t slow down the development. Not following this principle can result in false priorities and impact clients’ budget goals negatively.

To deepen the understanding of technical debt and what consequences it might have, you can take a quick look at our Technical Debt article:

What also significantly helps is when clients cooperate on specifying the requirements as much as possible. We fully understand that it’s not always possible to distinctly express what exactly clients want to see in their apps. But what’s important is willing to finally reach a point where it’s crystal clear what the next steps are. And we as Tech Partners always make sure to provide sufficient support in that regard:

• We ask the right questions.
• We always provide feedback and explain important technical characteristics.
• We stay agile and adjust the development plan on the go.

Such an approach can also help to reduce the number of changes that would have to be implemented during the process of delivery. It surely saves budget and reduces Time-to-Market.

Last but not least, feeling the involvement of the client is something that boosts the energy of team members. The fact that we deliver high-quality projects no matter what isn’t even a question, but still — it’s always good to know that the customer and we are on the same page and want to build a great solution together.

Despite the diversity of Project Management methodologies and tools, custom adjusting PM to each new project is of high importance — use cases might have to common patterns but are still unique.

That’s why creating a set of Project Management methods that allows you to stay resilient to unstable external factors (changing development standards, new priorities of the project that clients find out about on the go, etc.) is also the key to delivering projects successfully.