Project Management

Product Development

Quality

Creation process

Effective Team

How to develop new functionality with maximum benefit for a product?

Prepare your team before active development is started

The main stakeholders for any functionality being developed are the business side (or product owner), UX designer, developer, and QA engineer. These 4 sides represent the point of view of what the system should do, how it should look, what can and can not be implemented, and what may go wrong or be missed. Having different people for each point of view will help reduce missing important points.

And yet, do not limit discussion with only these sides. Depending on the functionality you are developing, you may find that other interested parties are needed to provide other points of view (marketing team, seo-specialist, support team, etc). But do not think that the bigger is the better. Include only people who are interested and will be involved in the implementation process. Do not include the whole team in discussion as this reduce team members’ sense of responsibility. As a result of passive participation - important points may be missed. Placing the right people in discussion is must done to achieve the best results. How get things done?

These nominal four parties must work together to determine what needs to be done, how to understand that it is done and done as expected. Once the functionality is implemented, each party should check the final result to make sure that it is still correct from the point of each view.

The first discussion should be immediately before user story implementation. Do not wait too late to add details and ask questions because the delay will slow development down. Do not start discussion too early - the details may become outdated, the context may change so that knowledge can no longer be applied.

Between the beginning and the end all key participants should communicate closely, so that any misunderstandings be discovered and corrected at an early stage and therefore any new ideas can be included. By continuous sharing the different perspectives on the functionality everyone can raise their concerns and resolve as soon as possible.

Why is it important?

This approach helps to avoid:

  • missing any details
  • confusion in user story understanding
  • rework

What can be difficult?

  • incorrect or incomplete workgroup composition. Members should be carefully considered.
  • too frequent discussions - instead of implementation. Discussion should be qualitative and detailed to resolve most of the questions before implementation is started.

In general these user stories discussions are short workshop with the team to understand the details and ensure everyone has all the information they need. But in the end it gives great value to the product.

31 SEP, 2023

4 mistakes in scaling long-running product and how to fix them

Our experience with building and delivering new core functionality into long-running products.

28 AUG, 2019

Work and relax simultaneously. Cyprus for IT-workers

The island in the eastern Mediterranean - Cyprus - is known as a popular outsourcing place for IT-workers from all over the world, and in particular from Europe. What exactly attracts them on this small piece of land among the waters of the Mediterranean

19 NOV, 2019

Step by step guide for creating WebSocket client in Golang using mutex and channel

In this guide to using WebSockets in Golang I would like to concentrate on the following: the application should work whether WebSocket server is online or not. The server can be offline for a number of reasons: poor connection, server issues, etc, but a

Help Ukraine to stop russian aggression