Productivity assessment
Posted: Sat Dec 28, 2024 8:31 am
Developers estimate tasks using the Fibonacci sequence. The goal is not to calculate the exact time for implementation, but to estimate the complexity of each task relative to others.
Fibonacci numbers (1, 2, 3, 5, 8, 13...) are a great help here - a gap of 2-3 or more points is more obvious than a gap of 1 point. It is obvious that a task worth 8 points is significantly more difficult than a task worth 5 points. And the difference between tasks worth 5 and 6 points would not be so obvious.
As a result, we have a rough understanding of the team's capacity. Before the start of the sprint, we see the task estimate and understand the development load: too much (something will have to be thrown out), just right, or the guys are underloaded and we can do refactoring.
Screenshot of Confluence
This is how developers present the results of retro sprints
We have a very cool synergy between the back and the front, that's where, but here we haven't had any disagreements for a very long time.
Denis
Backend developer
We tie all our work to business goals. Within the product team, we decompose them into areas of responsibility. For developers, this is the speed of development, timeliness of sprint closure, number of errors, contribution to the project, scalability of the solution. For product managers, this is the dynamics of key metrics (conversions, churn rate, WAU, MAU) + the number of tested hypotheses.
Forming a backlog
Now we look at the backlog of tasks every 2 weeks and rethink something, throw something out, set priorities and, in general, approach planning super-flexibly. For this, product managers have a special meeting - Pre-planning.
All future tasks should be described according to the structure:
The problem, hypothesis and potential of the feature are indicated.
The goal is written down - a brief description of what needs to be done.
A to-do list is provided - the main stages of work.
The technical specifications have been drawn up.
Links to external resources are provided where necessary.
On important and technically complex projects, product managers always importance of ig database consult with developers and designers. The guys can ban an idea (with good reason) and offer an alternative. In our team, developers are not just performers of tasks invented by someone, but full participants in the design of features.
An important point is that we prioritize all tasks. At the dawn of the business, when the product was very green, it was obvious what to do next. Now we have a bigger product, a bigger team, more business areas - now we can’t do without prioritization. We combine ROI and RICE assessment.
We didn't arrive at the current structure of working with the backlog right away. Here's what we tested:
The developers read the tasks for the next sprint during the current sprint and asked clarifying questions. This didn't work for us — the guys had to switch between 25 tabs, check plans for a new feature, study something, and still manage to write code. We soon abandoned this method, because it is important for developers, like product managers, to always be in the context of a specific task.
We held groomings weekly. Grooming is a team meeting to discuss ("comb") the backlog and clarify the details of tasks. Often, such meetings turned into discussions without specific solutions. Now we hold groomings when needed, and not because there is a meeting on the calendar.
Fibonacci numbers (1, 2, 3, 5, 8, 13...) are a great help here - a gap of 2-3 or more points is more obvious than a gap of 1 point. It is obvious that a task worth 8 points is significantly more difficult than a task worth 5 points. And the difference between tasks worth 5 and 6 points would not be so obvious.
As a result, we have a rough understanding of the team's capacity. Before the start of the sprint, we see the task estimate and understand the development load: too much (something will have to be thrown out), just right, or the guys are underloaded and we can do refactoring.
Screenshot of Confluence
This is how developers present the results of retro sprints
We have a very cool synergy between the back and the front, that's where, but here we haven't had any disagreements for a very long time.
Denis
Backend developer
We tie all our work to business goals. Within the product team, we decompose them into areas of responsibility. For developers, this is the speed of development, timeliness of sprint closure, number of errors, contribution to the project, scalability of the solution. For product managers, this is the dynamics of key metrics (conversions, churn rate, WAU, MAU) + the number of tested hypotheses.
Forming a backlog
Now we look at the backlog of tasks every 2 weeks and rethink something, throw something out, set priorities and, in general, approach planning super-flexibly. For this, product managers have a special meeting - Pre-planning.
All future tasks should be described according to the structure:
The problem, hypothesis and potential of the feature are indicated.
The goal is written down - a brief description of what needs to be done.
A to-do list is provided - the main stages of work.
The technical specifications have been drawn up.
Links to external resources are provided where necessary.
On important and technically complex projects, product managers always importance of ig database consult with developers and designers. The guys can ban an idea (with good reason) and offer an alternative. In our team, developers are not just performers of tasks invented by someone, but full participants in the design of features.
An important point is that we prioritize all tasks. At the dawn of the business, when the product was very green, it was obvious what to do next. Now we have a bigger product, a bigger team, more business areas - now we can’t do without prioritization. We combine ROI and RICE assessment.
We didn't arrive at the current structure of working with the backlog right away. Here's what we tested:
The developers read the tasks for the next sprint during the current sprint and asked clarifying questions. This didn't work for us — the guys had to switch between 25 tabs, check plans for a new feature, study something, and still manage to write code. We soon abandoned this method, because it is important for developers, like product managers, to always be in the context of a specific task.
We held groomings weekly. Grooming is a team meeting to discuss ("comb") the backlog and clarify the details of tasks. Often, such meetings turned into discussions without specific solutions. Now we hold groomings when needed, and not because there is a meeting on the calendar.