Distributed Team Anatomy - Requirements Preparation Process
We all know what kind of pain in various parts of the body causes problems with the requirements of everyone in Software Development. It would seem that even firms that have long been on the market should already have holistic practices of formalization and preparation of requirements - an-no, the process in most cases is quite primitive, and is not described anywhere. This is enough for someone, but in my case our team is also distributed, and even with the language barrier (K-K-Combo!).
Disclaimer: Each organization is unique - from the internal structure, and before it communicates with the outside world. So I do not consider any workflow (or business process, as they like to say in Russian) a universal solution. The post does not pretend to be complete and exclusive, it is rather that a similar approach works in SkuVault, in the current configuration of the team, and shows positive results. Our specifics are 50 people, 16 of whom are separated from another part by a 10-hour time difference.
Let's start with the thesis that for the sake of maximum developer productivity, the management should (except for the human attitude towards the employee):
')
- Develop a clear process of “who to ask if requirements are not clear”
- Good description and decomposition requirements
- No context switching or distractions (as far as possible)
We wrote down a team of “fire extinguishers”, which fixes urgent things (given that the system uses a bunch of companies, problems arise constantly) - so we minimized context switching for developers. (greetings to Kniberg and Scrum from the Trenches 2nd edition - fire fighting teams are also described there - it's nice to realize that we use good practice, which we came to ourselves). Here we must understand that we had to significantly invest time in the transfer of knowledge, but where do without it =)
But with the processes of precisely preparing the requirements for development, until relatively recently, there was a misfortune - there was no formalization from the word at all. The more features we sawed and the product grew, the more dependencies were found. We stuffed bumps on typical scenarios of companies with an exponentially growing product: constant changes in requirements, a communication curve, conflicting scenarios, and lack of integrity.
In order to make it common and transparent to work on the preparation of requirements for all the departments involved, we created a “Process for Requirements Management” (or Product Management Workflow. Further Workflow == Process).
The process for large, juicy, new features was to achieve the following goals:
- Must have simple and concrete steps
- Each step should be in the introduction of the responsible person, and as transparent as possible for all involved in the other steps.
- Vorkflou should provoke more discussions and diversified vzlyad (truth arises in disputes) → so that there are no incorrectly interpreted sentences, and the details of the requirements were forged together
- Each step provided higher quality requirements than before. This is achieved by specific criteria of completeness, checked on the output.
The process consists of consecutive steps:
New Task (New Issue) → Research (Discovery) → Matching (Sign Off) → Formalization (Analysis)
* We have Atlassian Jira.
The ticket is created by a trigger from a variety of sources, whether it be marketing, support, developers, a client dodging feedback forms. At this stage, the ticket is empty enough, showing only the original request, and its source.
Transition to the next stage: In order to proceed to the next stage, the Product Owner / Manager, in general, the person responsible for this, assesses whether we will do this feature at all (ever).
- If not - the ticket is closed.
- Yes, someday - we throw in the Backlog (and there is an abyss, from which there is little to climb out =).
- Yes, in the near future - the ticket moves to the “Research” stage.
The goal of the step is that the PO should highlight the goal of the feature (what we need to achieve, what advantages our company will bring and what advantages it will bring to users). Describe the basic business process (1-2 proposals on how the feature works in the warehouse, as we are doing PaaS warehouse automation system).
Example
Since the flow of tickets can be tight and rapid, we allow stakeholders to negotiate tickets in bulk. Anticipating the questions of people working on the scram "Hey, how can it be, because the Product Owner should do this!", I will answer that the product is large (with a ton of subprojects and areas of application) and no product is enough (and even two). Well and on this coordination there are people from support, those. department, marketing - each has its own goal, but with a common desire (obviously, to make the project better).
The purpose of the step: to harmonize the idea, the generalized process of its work, and the time to market.
This is where the greatest amount of work begins, the most collaborative, and, in addition, difficult. It includes Analysts, Developers, UX-comrades, notorious POs - and they all write User Story, draw prototypes, run to customers and partners with clarifications, criticize and make up the Sisyphus feedback loop (irony and self-criticism never hurt).
At the exit (ideally), you should get: concrete, broken into pieces User Story, in which subtasks are tickets for the backend, with estimates of the timing of implementation - which in turn allows us to estimate the size, timing, conflicts during the development of features. Worning: estimeyty should not go into deadlines, it is just a convenient measure of evaluation, which is then iterated a few more times.
An example of a User Story (a formalized, easy-to-understand description of user actions for a specific purpose, for example, interaction with an interface).
We have quite strict rules for the design of a user story, technical subtasks, requests from support and bug reports. This kind of protection from the fool, and the same system of standards for the entire task-tracking system, for different types of tasks. Thanks to her, the understanding of the requirements appears to everyone (even those who shied away from this ticket), and it would not be possible to interpret the dual problem.
In general and in general, this our Workflow simplified and standardized the format of requirements, we added components to the ticket to it - and there is no conflict at all between the requirements for specific components (all related tasks are immediately visible). The quality of requirements has improved (but after long observations, pointing fingers at inconsistencies, and shouting about redundancy). Changes in requirements occur less frequently (because more factors are initially taken into account), the transparency of the process guarantees an understanding of what stage we are at. Of course, the systems are now redundant, and, as can be seen on the kanban board, there must be combined and simplified steps, but we are moving in a definitely right direction =)
PS: for those people who say that workflow is redundant, and is not suitable for simpler features - you are right, the simplified scheme for simple tasks is attached below.
Disclaimer: Each organization is unique - from the internal structure, and before it communicates with the outside world. So I do not consider any workflow (or business process, as they like to say in Russian) a universal solution. The post does not pretend to be complete and exclusive, it is rather that a similar approach works in SkuVault, in the current configuration of the team, and shows positive results. Our specifics are 50 people, 16 of whom are separated from another part by a 10-hour time difference.
Problems
Let's start with the thesis that for the sake of maximum developer productivity, the management should (except for the human attitude towards the employee):
')
- Develop a clear process of “who to ask if requirements are not clear”
- Good description and decomposition requirements
- No context switching or distractions (as far as possible)
We wrote down a team of “fire extinguishers”, which fixes urgent things (given that the system uses a bunch of companies, problems arise constantly) - so we minimized context switching for developers. (greetings to Kniberg and Scrum from the Trenches 2nd edition - fire fighting teams are also described there - it's nice to realize that we use good practice, which we came to ourselves). Here we must understand that we had to significantly invest time in the transfer of knowledge, but where do without it =)
But with the processes of precisely preparing the requirements for development, until relatively recently, there was a misfortune - there was no formalization from the word at all. The more features we sawed and the product grew, the more dependencies were found. We stuffed bumps on typical scenarios of companies with an exponentially growing product: constant changes in requirements, a communication curve, conflicting scenarios, and lack of integrity.
In order to make it common and transparent to work on the preparation of requirements for all the departments involved, we created a “Process for Requirements Management” (or Product Management Workflow. Further Workflow == Process).
Product Requirements Management
Goals
The process for large, juicy, new features was to achieve the following goals:
- Must have simple and concrete steps
- Each step should be in the introduction of the responsible person, and as transparent as possible for all involved in the other steps.
- Vorkflou should provoke more discussions and diversified vzlyad (truth arises in disputes) → so that there are no incorrectly interpreted sentences, and the details of the requirements were forged together
- Each step provided higher quality requirements than before. This is achieved by specific criteria of completeness, checked on the output.
Steps
The process consists of consecutive steps:
New Task (New Issue) → Research (Discovery) → Matching (Sign Off) → Formalization (Analysis)
New Task
* We have Atlassian Jira.
The ticket is created by a trigger from a variety of sources, whether it be marketing, support, developers, a client dodging feedback forms. At this stage, the ticket is empty enough, showing only the original request, and its source.
Transition to the next stage: In order to proceed to the next stage, the Product Owner / Manager, in general, the person responsible for this, assesses whether we will do this feature at all (ever).
- If not - the ticket is closed.
- Yes, someday - we throw in the Backlog (and there is an abyss, from which there is little to climb out =).
- Yes, in the near future - the ticket moves to the “Research” stage.
Study
The goal of the step is that the PO should highlight the goal of the feature (what we need to achieve, what advantages our company will bring and what advantages it will bring to users). Describe the basic business process (1-2 proposals on how the feature works in the warehouse, as we are doing PaaS warehouse automation system).
Example
Brief description of shipments functionality
Departures and Track numbers are a way to track the movement of goods in the order that we / the third-party logistics office sent to the user. Dispatch is created in the system as soon as the track number to order is assigned by the delivery service. The system should allow to add and save track numbers so that users can see the delivery information and edit it directly in the application.
What we want to achieve
To allow users to use courier services that are not integrated with e-commerce stores through our system.
How
Call customers to mark products with track numbers, and see information on shipments of orders to which these goods are attached.
How does it work in stock
1. The person collecting the order is coming to the quality control table.
2. The person who checks the integrity of the package is enough, checks it, and if everything is ok, then it will glue the label with the delivery information and the track number
3. The track number is added to the system, and in the “delivery” tab of the product we see to everyone who opens the product page
4. You can view the delivery status on the product page.
Matching
Since the flow of tickets can be tight and rapid, we allow stakeholders to negotiate tickets in bulk. Anticipating the questions of people working on the scram "Hey, how can it be, because the Product Owner should do this!", I will answer that the product is large (with a ton of subprojects and areas of application) and no product is enough (and even two). Well and on this coordination there are people from support, those. department, marketing - each has its own goal, but with a common desire (obviously, to make the project better).
The purpose of the step: to harmonize the idea, the generalized process of its work, and the time to market.
Analysis and Formalization
This is where the greatest amount of work begins, the most collaborative, and, in addition, difficult. It includes Analysts, Developers, UX-comrades, notorious POs - and they all write User Story, draw prototypes, run to customers and partners with clarifications, criticize and make up the Sisyphus feedback loop (irony and self-criticism never hurt).
At the exit (ideally), you should get: concrete, broken into pieces User Story, in which subtasks are tickets for the backend, with estimates of the timing of implementation - which in turn allows us to estimate the size, timing, conflicts during the development of features. Worning: estimeyty should not go into deadlines, it is just a convenient measure of evaluation, which is then iterated a few more times.
An example of a User Story (a formalized, easy-to-understand description of user actions for a specific purpose, for example, interaction with an interface).
“As a user, I want to see the ordering information in a separate tab”
Pre-condition: user on the page “Ordering Information”
1. In the header of the page there is a hint “Click on the“ Shipments ”tab for additional information on shipments”
2. The user clicks on the tab. The information tab is located in the following order (field-value table):
- Shipping Information
- Tracking number link
- Created Date
- Carrier
- Class
- Shipped Items Count (link)
- Shipment Costs (link)
- Cost Type
- Cost Amount
- Total
- and so on
3. The user can click on Shipped Items, or Total Cost, to see additional information on the breakdown of the goods within the order. Information is displayed in a modal window.
4. If a link to the track number is given, then by clicking on it, a new tab should open in the browser, going to the tracking page of the courier service
4.1 If there is no link to the track information at the courier, then the user simply shows an empty field, instead of a link
5. Under the list of fields is the button "Download", which allows you to download all the information in PDF
Post-condition: the user has the opportunity to see the delivery information in the “Shipment” tab, on the order page.
We have quite strict rules for the design of a user story, technical subtasks, requests from support and bug reports. This kind of protection from the fool, and the same system of standards for the entire task-tracking system, for different types of tasks. Thanks to her, the understanding of the requirements appears to everyone (even those who shied away from this ticket), and it would not be possible to interpret the dual problem.
Summarizing
In general and in general, this our Workflow simplified and standardized the format of requirements, we added components to the ticket to it - and there is no conflict at all between the requirements for specific components (all related tasks are immediately visible). The quality of requirements has improved (but after long observations, pointing fingers at inconsistencies, and shouting about redundancy). Changes in requirements occur less frequently (because more factors are initially taken into account), the transparency of the process guarantees an understanding of what stage we are at. Of course, the systems are now redundant, and, as can be seen on the kanban board, there must be combined and simplified steps, but we are moving in a definitely right direction =)
PS: for those people who say that workflow is redundant, and is not suitable for simpler features - you are right, the simplified scheme for simple tasks is attached below.
Source: https://habr.com/ru/post/345302/
All Articles