This document provides guidance on how to cooperate with a technical team when developing a software product. It discusses preparing initial requirements, having a scoping session to discuss goals and expectations, formulating user stories to define functional requirements, getting estimations from the technical team, conducting a kickoff meeting to introduce the methodology, and maintaining daily contact through established communication channels. Key steps include preparing documentation of requirements, questions, and a product vision before meeting with the technical team to align on priorities and next steps. Functional requirements and user stories should define features from the user's perspective using a structured format. The technical team will provide estimations of effort based on their experience with similar functionality.

1. 9/X
How to cooperate with
Technical Teams
By

2. 9/X
1. Preparing Initial Requirements
2. Workshop / Scoping Session with a Technical Team
3. Formulating Functional Requirements / User Stories
4. Estimations
5. Kickoff and introduction to Methodology
6. Daily contact with programmers (+ valuable comments)
WHAT ARE WE GOING TO TALK ABOUT?

3. I have a Startup / Company - what do I have to specify at the planning stage before starting any activities
and before talking to a technical team?
PREPARING INITIAL REQUIREMENTS
3
Problem Summary Main Function -
Goals
Design + Tech
Stack
After preparing the document with the initial requirements, product summary and after arranging a
Scoping Session / Workshop, it is a good idea to share this file with the technical team.

4. 1. Introduction
2. General questions (to warm up)
3. Presentation of the product vision
4. Technical questions
5. Questions about design / style
6. Meeting summary
1. Expected results
2. Next steps
WORKSHOP / SCOPING SESSION WITH A TECHNICAL TEAM
4
The goal of this meeting is to get acquainted with your idea, expectations, determine priorities and discuss business goals.
On the client side: PO / Founder
On the software house side: PM or Business Analyst, Designer and Developer or several Developers.
At the meeting should be:
Course example of a meeting
1. Meeting summary
2. Additional questions
3. Preliminary estimations
After a meeting

5. 9/X
• functional criteria of the system - how the function should work from the Users point of view
• eg: step-by-step operation - compliance of the operation with the prepared User Flow.
FORMULATING FUNCTIONAL REQUIREMENTS / USER STORIES
WHAT DOES IT MEAN?
A functional requirement is a requirement regarding the result of system behavior that
should be provided by a system function.
Definition of Functional Requirements:
As (role), I want (feature),by (reason)
An example of a User Story structure
5

6. 9/X
1. Consistency - descriptions of requirements in the specification can not contain contradictions.
2. Ordering - requirements should be explicitly classified in terms of validity by PO, e.g. Must-Have, Should-Have and Nice-to-
have.
3. Verifiability - descriptions of requirements should be formulated in such a way that it is possible to unambiguously determine
whether the final product meets these requirements or not.
Non-functional requirements
The performance or quality criteria are specified often only by the Technical Team (eg availability, response time, and
maintenance options.)
FORMULATING FUNCTIONAL REQUIREMENTS / USER STORIES
6
Features of Functional Requirements / Stories:

7. 9/X
Estimation is guessing. Estimation is prepared by a technical team - developers and/or a designer. A
new estimation is based on developer’s experience with work on a similar functionalities.
Out of Scope - correcting bugs / errors, refactoring the code, functionalities reported during a Sprint.
ESTIMATIONS
7

8. 9/X
ESTIMATIONS
8
He reads the customer's Brief, Product Specification and prepares questions to the PO / customer in order to dispel doubts.
Meets internally with the rest of the team or another developer to discuss the best approach to building a product.
What does the technical team do to make Estimation as close as possible to reality?
Function; Time in MDs containing (planning + actual work + tests + code review); Expense; Comment.
Prepares the document in which the listed columns are located:
The document is then sent to the PO / customer.

9. 9/X
1. Before the meeting PM should prepare: Documentation
based on Client’s materials, epics, preliminary tickets.
2. Team introduction.
3. Forms of contact (Slack, Jira, Confluence, Mail, Where we
should keep all the arrangements we maintain and how we
communicate.
4. Discuss the Methodology(Sprint Planning, Daily, Sprint
Review, Definition-of-Done, etc.)
5. Rules of Cooperation (For example who is responsible for a
Sprint Backlog, Final tests and acceptance of tickets, etc.).
KICK-OFF AND INTRODUCTION TO METHODOLOGY
9
Kick off:

10. 9/X
1. Keep communications on the public channels.
2. Do not write directly to programmers - ask a PM about
everything first.
3. Problem / error reporting process should be clear.
DAILY CONTACT WITH PROGRAMMERS (+ VALUABLE TIPS)
1. Keep everything on "paper" - Slack, Jira, Confluence.
2. When reporting Bugs, describe the place of occurrence and steps (+ Screenshots)
very accurately.
3. Be polite and professional.
4. Respect your and developer’s time - be prepared for meetings and do not cancel
them.
5. Have a prepared plan of meetings in which the developers participate.
6. Define and set priority for your goals and tickets.
7. Do not call without a good reason.
8. After a good job - honestly thank everyone ;)
10
Principles of cooperation: Tips

11. 11
Q&A