December 22, 2017 at 11:33Distributed Team Anatomy - Requirements Preparation Process
We all know what pain in different parts of the body causes problems with the requirements of everyone involved in the Software Development. It would seem that even offices that have long been on the market should already have holistic practices of formalizing and preparing requirements - no, the process in most cases is quite primitive, and is not scheduled anywhere. This is enough for someone, but in my case our team is also distributed, and even with a language barrier (k-k-kkombo!).
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 speak Russian) a universal solution. The post does not claim to be complete and exclusive, it is more likely that a similar approach works for us in SkuVault, in the current configuration of the team, and shows positive results. Our specifics is 50 people, 16 of which are torn from another part by a 10-hour time difference.
Let's start with the thesis that for the sake of maximum developer productivity, management should (except for the human attitude to the employee):
- Develop a clear process of “who to ask in case of incomprehensibility of requirements”
- Good description and decomposition of requirements
- No context switching and distractions (as much as possible)
We filmed a team of "fire extinguishers" that fixes urgent things (given that the system is used by a bunch of companies, problems arise constantly) - this way we minimized context switching for developers. (hello Kniberg and Scrum from the Trenches 2nd edition - fire extinguishing teams are also described there - it's nice to realize that we are using the good practice that we ourselves have come to). Here you need to understand that you had to significantly invest time in the transfer of knowledge, but where would it be without =)
But with the processes specifically for preparing development requirements, until relatively recently, there was a disaster - there was no formalization from the word at all. The more features we saw and the product grew, the more dependencies were found. We filled the bumps on typical scenarios of companies with exponentially growing products: constant changes in requirements, curve communication, conflicting scenarios and lack of integrity.
In order to make the preparation of requirements for all involved departments general and transparent, we have created a “Process for Requirements Management” (or Product Management Workflow. Further Workflow == Process).
The process for large, juicy, new features should have achieved the following goals:
- It should have simple and specific steps
- Each step should be a responsible person, and as transparent as possible for all those involved in other steps
- Workflow should provoke more discussion and a diverse look ( truth is born in disputes) → so that there are no incorrectly interpreted sentences, and details of requirements are forged together
- Each step provided a higher quality of requirements than before. This is achieved by specific criteria of completeness, checked at the exit.
The process consists of successive steps:
New Issue → Discovery → Sign Off → Analysis
* We have Atlassian Jira.
A ticket is created by a trigger from a variety of sources, be it marketing, support, developers, a customer shy in feedback forms. At this stage, the ticket is empty enough, showing only the initial request, and its source.
Going to the next stage: In order to go to the next stage, Product Owner / Manager, in general, the person responsible for this, evaluates whether we will do this feature at all (ever).
- If not, the ticket closes.
- Yes, someday - we throw in the Backlog (and there is an abyss, from which little gets out =).
- Yes, in the near future - the ticket is moving to the “Investigation” stage.
The goal of the step - the PO should highlight the goal of the feature (what we need to achieve, what kind of goodies of our company it will bring, and which ones will bring advantages to users). Describe the basic business process (1-2 sentences on how the feature works in the warehouse, since we are making a PaaS warehouse management automation system).
Example
Since the flow of tickets can be tight and rapid, we allow stakeholders to coordinate tickets in bulk. Anticipating the questions of people working on the “Hay, why not, Product Owner should do it!” Answer, I’ll answer that the product is large (with a ton of subprojects and applications) and there isn’t any product (or even two). Well, at this agreement 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 goal of the step: to coordinate the idea, the generalized process of its work, and the timing of entering the market.
This is where the biggest amount of work begins, the most collaborative, and, in addition, the most difficult. It includes Analysts, Developers, UX-comrades, the notorious POs - and they all write User Story, draw prototypes, run to clients and partners with clarifications, criticize and make up the Sisyphus feedback loop (irony and self-criticism will never hurt).
At the output (ideally), you should get: specific User Story, broken into pieces, in which the tickets for the backend are sub-tasks, with estimates on the timing of implementation - which in turn allows you to estimate the size, timing, conflicts during the development of features. Waring: Estimates should not go into deadlines, this is just a convenient measure of evaluation, which is then iterated several more times.
User Story example (formalized, easy-to-understand description of user actions for a specific purpose, using interaction with the interface as an example).
We have fairly strict rules for the design of user story, technical subtasks, requests from support and bug reports. A kind of protection against the fool, and the same system of standards throughout the task tracking system, for different types of tasks. Thanks to her, everyone understands the requirements (even those who shy away from this ticket), and they won’t be able to interpret the task doubly.
In general and in general, this our Workflow simplified and standardized the requirements format, we added components to tickets in it - and there are no conflicts between requirements for specific components (you can immediately see all the related tasks). The quality of requirements has improved (but after long observations, poking a finger 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 ensures 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 you need to combine and simplify the steps, but we are moving in the definitely right direction =)
PS: for those people who say that workflow is redundant, and is not suitable for simpler features - you're right, a 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 speak Russian) a universal solution. The post does not claim to be complete and exclusive, it is more likely that a similar approach works for us in SkuVault, in the current configuration of the team, and shows positive results. Our specifics is 50 people, 16 of which are torn from another part by a 10-hour time difference.
Problems
Let's start with the thesis that for the sake of maximum developer productivity, management should (except for the human attitude to the employee):
- Develop a clear process of “who to ask in case of incomprehensibility of requirements”
- Good description and decomposition of requirements
- No context switching and distractions (as much as possible)
We filmed a team of "fire extinguishers" that fixes urgent things (given that the system is used by a bunch of companies, problems arise constantly) - this way we minimized context switching for developers. (hello Kniberg and Scrum from the Trenches 2nd edition - fire extinguishing teams are also described there - it's nice to realize that we are using the good practice that we ourselves have come to). Here you need to understand that you had to significantly invest time in the transfer of knowledge, but where would it be without =)
But with the processes specifically for preparing development requirements, until relatively recently, there was a disaster - there was no formalization from the word at all. The more features we saw and the product grew, the more dependencies were found. We filled the bumps on typical scenarios of companies with exponentially growing products: constant changes in requirements, curve communication, conflicting scenarios and lack of integrity.
In order to make the preparation of requirements for all involved departments general and transparent, we have created a “Process for Requirements Management” (or Product Management Workflow. Further Workflow == Process).
Product Requirements Management
Goals
The process for large, juicy, new features should have achieved the following goals:
- It should have simple and specific steps
- Each step should be a responsible person, and as transparent as possible for all those involved in other steps
- Workflow should provoke more discussion and a diverse look ( truth is born in disputes) → so that there are no incorrectly interpreted sentences, and details of requirements are forged together
- Each step provided a higher quality of requirements than before. This is achieved by specific criteria of completeness, checked at the exit.
Steps
The process consists of successive steps:
New Issue → Discovery → Sign Off → Analysis
New Challenge
* We have Atlassian Jira.
A ticket is created by a trigger from a variety of sources, be it marketing, support, developers, a customer shy in feedback forms. At this stage, the ticket is empty enough, showing only the initial request, and its source.
Going to the next stage: In order to go to the next stage, Product Owner / Manager, in general, the person responsible for this, evaluates whether we will do this feature at all (ever).
- If not, the ticket closes.
- Yes, someday - we throw in the Backlog (and there is an abyss, from which little gets out =).
- Yes, in the near future - the ticket is moving to the “Investigation” stage.
Study
The goal of the step - the PO should highlight the goal of the feature (what we need to achieve, what kind of goodies of our company it will bring, and which ones will bring advantages to users). Describe the basic business process (1-2 sentences on how the feature works in the warehouse, since we are making a PaaS warehouse management automation system).
Example
A brief description of the shipments functionality Shipments
and Track numbers are a way to monitor the movement of goods in an order that we / a third-party logistics office sent to the user. A shipment is created in the system as soon as the track number for the order is assigned by the delivery service. The system should allow you to attach and save track numbers so that users see delivery information and can edit it directly in the application.
What we want to achieve.
Give users the opportunity to use courier services that do not integrate with e-commerce stores through our system.
How to
Call customers to mark products with track numbers, and see information on order shipments to which these products are attached.
How it works in the warehouse
1. The person collecting the order comes to the quality control table
2. The person who checks the integrity grabs the packaging, checks it, and if everything is ok, it sticks a label with the delivery information and track number
3. Track number is added to the system, and in the product tab “delivery” we see everyone who opens the product page
4. You can see what the delivery status is on the product page
Matching
Since the flow of tickets can be tight and rapid, we allow stakeholders to coordinate tickets in bulk. Anticipating the questions of people working on the “Hay, why not, Product Owner should do it!” Answer, I’ll answer that the product is large (with a ton of subprojects and applications) and there isn’t any product (or even two). Well, at this agreement 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 goal of the step: to coordinate the idea, the generalized process of its work, and the timing of entering the market.
Analysis and Formalization
This is where the biggest amount of work begins, the most collaborative, and, in addition, the most difficult. It includes Analysts, Developers, UX-comrades, the notorious POs - and they all write User Story, draw prototypes, run to clients and partners with clarifications, criticize and make up the Sisyphus feedback loop (irony and self-criticism will never hurt).
At the output (ideally), you should get: specific User Story, broken into pieces, in which the tickets for the backend are sub-tasks, with estimates on the timing of implementation - which in turn allows you to estimate the size, timing, conflicts during the development of features. Waring: Estimates should not go into deadlines, this is just a convenient measure of evaluation, which is then iterated several more times.
User Story example (formalized, easy-to-understand description of user actions for a specific purpose, using interaction with the interface as an example).
“As a user, I want to see information about sending an order in a separate tab”
Pre-condition: user on the page “Order information”
1. In the header of the page there is a hint “Click on the tab“ Departures “for additional information on shipments”
2. 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 goods inside the order. Information is displayed in a modal window.
4. If a link to the track number is given, then clicking on it should open a new tab in the browser that goes to the tracking page of the courier service
4.1 If the courier does not have a link to the track information, then the user is simply shown an empty field, instead of link
5 Under the list of fields is the “Download” button, which allows you to upload all the information in a PDF
Post-condition: the user has the opportunity to see the delivery information in the “Departure” tab, on the order page.
We have fairly strict rules for the design of user story, technical subtasks, requests from support and bug reports. A kind of protection against the fool, and the same system of standards throughout the task tracking system, for different types of tasks. Thanks to her, everyone understands the requirements (even those who shy away from this ticket), and they won’t be able to interpret the task doubly.
Summarizing
In general and in general, this our Workflow simplified and standardized the requirements format, we added components to tickets in it - and there are no conflicts between requirements for specific components (you can immediately see all the related tasks). The quality of requirements has improved (but after long observations, poking a finger 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 ensures 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 you need to combine and simplify the steps, but we are moving in the definitely right direction =)
PS: for those people who say that workflow is redundant, and is not suitable for simpler features - you're right, a simplified scheme for simple tasks is attached below.