Under The Hood: How We Build Processes In The Development Department
2. Project? → Product? → CEO?
3. Where the ideas come from
3.1 Feedback/requests from users
3.2 Competitor analysis
3.3 Generation of ideas by team members
4. Validation of ideas, planning, thinking over details, design
5. Task preparation and sprint planning
6. Development, testing, release
7. Bugs, problems, user requests
8. Interaction with other departments: (Marketing, Sales and Customer Success, Support)
9. Routine, meetings
10. Sprint control, statistics collection
The start of a sprint is Tuesday, the end of a sprint is Monday. We chose this schedule not to end the sprint on Friday and release before the weekend; if an issue occurs, it wouldn't have to be fixed on Saturday/Sunday.
My team has four developers and two testers. There are also two designers whose work and tasks we share between other teams.
The purpose of the sprint is to release at least one visible feature for users, fix bugs and optimize the service.
The team faces difficulties during the sprint due to bugs, requests from users, and team members' illnesses.
Sprint time was distributed in the following proportions:
We are not the classic managers that are written about in articles and books. Being a manager at Serpstat is an excellent opportunity to jump through hoops. We have established processes, but this doesn't mean that they don't change. It is a flexible, breathing system that responds to many factors. We follow the list of rules and flow to achieve maximum efficiency, speed, and quality.
Each Project/Product Manager at Serpstat is a universal soldier who manages more than just a development team or a separate module. He searches for ideas or generates them himself, validates them with the help of surveys and analytics, describes, discusses with the team, interacts with the UX designer to get the most convenient and simple layout.
Quite a lot of time is spent on thinking through an idea, as well as many small things that are associated with the rest of the product. We don't have separate technical writers, so the writing of ToR and documentation also falls entirely on the manager. And besides all this, monitoring the sprint itself, meetings with developers, maintaining spirit in the team, reporting, and many more are also a part of a manager's work.
The main objective is a full development cycle, including issues such as data storage, promotion tasks for the marketing department, documentation for Customer Support department, demonstrations and presentations for Sales and Customer Success departments.
My area of responsibility is the Rank Tracker module, which allows users to track site positions in the search results for specific keywords.
Additionally, on support, there is a SERP Crawling feature for keywords through the API.
Leave a request, and our experts will advise you on the development of your project, share training materials, and offer test access to Serpstat!
Direct request: "Add sorting by frequency in the Keywords report for rank tracking."
Indirect request: "It is inconvenient to use the report because of the long name of the region since the column takes up a lot of space."
In a direct request, it is most often clear what needs to be done; in an indirect, we discuss it with our UX designer and look for an acceptable solution to the user's problem.
Sources of such reviews:
All attractive features are written to a special form and further discussed with the teamlead.
For each feature, we add the following parameters:
The next step is to add the product to the backlog; it is stored in Google Spreadsheets with minimal detail and filters.
Every 2-3 weeks, depending on the speed of collecting requests, the entire team of PMs (including team lead) assess the viability of the idea and set priorities within the product.
Previously, the primary indicator that a particular feature needs to be implemented was only the number of requests from different sources. But it was risky because we could spend several sprints without a visible result, while other, smaller features were idle, although they could greatly simplify the lives of our customers now.
A few months ago, we implemented the RICE system as the basis for evaluation. Our team leader adapted it to the realities of the product to evaluate our users' requests.
We evaluate the feature by 4 parameters:
4 - users of three or more modules;
3 - users of two modules;
2 - all users of one module;
1 - individual users of one module.
Lead product manager adds it when adding features to the backlog.
4 — 8−9;
3 — 6−7;
2 — 4−5;
1 — 3.
Lead product manager adds it when analyzing the tab where we store the feedback from users.
4 - rather sure;
3 - 50/50;
2 - rather unsure;
1 - not sure.
It is added by poker lead using the planitpoker service.
This parameter shows how each PM considers the feature useful for the product at this stage with the current level of implementation.
4 — 3;
3 — 2;
2 — 1;
1 — <1.
Each PM estimates an approximate number of sprints necessary for feature implementation. Sometimes it is required to conduct preliminary research to determine the possibility more accurately. Often in simple features, PM himself can estimate the time. This includes all stages, from design to final testing and release to a production server.
Sources of requirements can be details from the analysis of competitors, direct requests from users, which can often be combined into a collective functional, and interview results. The module manager describes the future vision of the tool and sets the task for the designer.
While working on a task, the initial vision is overgrown with details designed to improve user experience: tips, validation of fields and input data, alerts with important information, etc.
To simplify the work of designers, I compiled a checklist with best practices, which must be taken into account when designing. Here are some examples:
Next, PM conducts a layout test for behavioral cases. Often, adding even one field or button entails many nuances that need to be displayed in the design.
Most often checked moments:
Story is a container for tasks, which is considered a minimum working set of functionality that is visible to the user.
Duty is a container for tasks solving optimization issues, problems related to technical debt, as well as other functions invisible to the user.
After the task is evaluated by complexity and gets an executor, the next step is to divide it into sub-tasks, which are assessed in hours.
An additional task is created for testing this functionality. One task should not exceed 7 hours so that it can be completed during the day since an hour will be spent on meetings and other things.
After all the stories and duties are divided into subtasks, PM plans how many tasks can be taken in the sprint. The remaining time is used for bug fixes - planned and unplanned.
If Story or Duty turns out to be very large, PM revises the functionality and divides it into several smaller tasks.
Code review is a process that allows all developers to double-check each other for compliance with general rules. With a code review, a task can return to a fix or go further for testing.
After the team leader received the task, the tester takes it to work. The tester checks the functionality for compliance with the description, passes all the positive use cases, and tests the most common negative ones. From testing, the task can return to clarify the newly opened case, to fix the bugs found, or it can be given the "Ready" status.
Every last Thursday of the sprint, the team lead of the development department collects all the tasks that have "Ready" status. They are collected in a separate GitLab release branch on the server and retested to ensure that there are no problems with the joint work of all the features.
Thursday, Friday, and Monday are dedicated to testing these tasks and bugs that are fixed at this time.
Tuesday is the day of release. All tasks that were tested together are deployed to the production server, where they become available to our users.
All Blocker and Critical bugs go to the current sprint. Bugs of lower priority are planned as part of the sprints. They are fixed after the release branch is built (a set of functionality that is tested separately and will become available to users after release).
If bugs that are lower in priority than those that were discovered during the iteration are included in the sprint, then they are replaced.
If the number of critical bugs exceeds the available time, they displace features from the sprint for which development has not yet begun.
If the number of bugs exceeds the available time in the sprint, or there are several Critical and Blocker bugs, or the module doesn't work, then developers from other teams are involved. Only the Daily meeting remains obligatory. We declare a military mode in the department which is controlled by the CTO. A PM keeps the CEO and heads of other departments up to date and updates statuses using a special telegram channel.
The Marketing department checks translations before uploading features to the production server (in the current version it is English, Ukrainian, and Russian), receives tasks for promoting certain essential elements in the module, and writes articles and posts about updates of the module.
The Sales department is provided with information about new features released and closed requests of individual users. Often, this becomes the starting point for re-calling with the lead to close the plan's purchase, as the necessary functions become available.
Information for the Customer success department allows them to record a webinar or train our users in cases that can be solved using the functionality that has appeared.
The Support department gets a clear idea of what functionality is currently available and how it should work. In this case, any deviation can be regarded as a bug, and with the help of support, it will be sent to the QA department, where they will open a bug.
Daily (10-15 minutes)
To synchronize all team members regarding the current status of tasks and their daily plan.
Daily is held twice. Initially, the manager takes part in the team daily. After that, he takes part in the daily between teams, where team members and all PMs participate.
The daily format implies answers to three main questions:
Sprint approval with Lead PM, CTO, VP of Product (15-30 minutes)
To approve the sprint with heads, get comments, edits, or recommendations on the sprint plan.
All tasks planned for the sprint are subject to additional verification/approval by VP of Product (at the moment this applies to the modules Search Analytics, Rank Tracker and Site Audit.)
This meeting is mandatory and is scheduled no later than three days before the sprint. There should be time for making changes and familiarizing the team with the tasks and their evaluation.
Technically complex and essential tasks that may affect the operation of other modules or related to data transfer and temporarily stop the process of the module are consulted and approved by CTO. The Lead product manager confirms the tasks of other teams and less critical.
Poker planning (60-90 minutes)
To evaluate all tasks according to the complexity index in SP (Story points) and discuss what is planned to be done in the next sprint.
Tasks are collected in a separate list and imported into the planitpoker service.
The difficulty scale is measured in Story Points on a scale: 1, 2, 3, 5 or ?, where
- 1sp - small style changes.
- 2sp - changes in the data format, alteration of components.
- 3sp - writing a procedure with 0 or creating a new component.
- 5sp - creating separate pages on the front, writing several procedures, or their substantial alteration.
- ? - I have questions regarding the description, I can't evaluate it.
Assessment of the task consists of several processes:
Sprint retrospective (45-60 minutes)
To evaluate what has been fixed since the last sprint, check the progress of the team, and give recommendations. Deal with the reasons for the failure of the sprint.
Sprint retrospective occurs the day after the sprint is released.
The meeting is divided into parts:
The manager prepares a list of tasks that were not completed as part of the sprint. Each team member has the opportunity to express their point of view on the reasons of the failure. Based on these comments, the manager is required to take the necessary actions to prevent a recurrence of the situation.
In Serpstat, each developer has a KPI system. Based on the results of the system, the best developer of the month and the best team of the quarter are selected. During the sprint, each member of the team has access to the results to track their positions.
This is a fairly flexible platform that can be further customized with the help of a large number of plug-ins, both paid and free.
In Redmine we store bugs and scheduled tasks for several sprints.
A minimum of the most useful information is displayed: whose task it is, its status, planned time and time spent.
We have a sprint success rate, measured as a percentage, which shows how many tasks were completed and closed in the current sprint from the ones planned at the beginning.
The metric was introduced to train teams to complete tasks on time and, accordingly, to increase the planning term for the release of important features.
The important points that we found out during this time:
Learn how to get the most out of Serpstat
Want to get a personal demo, trial period or bunch of successful use cases?
Send a request and our expert will contact you ;)
Cases, lifehacks, researches and useful articles
Don’t you have time to follow the news? No worries!
Our editor Stacy will choose articles that will definitely help you with your work. Join our cozy community :)