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.
