Regrouping With the Help of the Data

Problem

A retrospective is a powerful tool for a manager to leverage. You hold them every two weeks or so; they allow you to look back over each sprint in order to determine how well the team did. You have a chance to identify inefficiencies that may be holding your team back.

If these processes are not yet in place, you need to take the initiative and instate them yourself. There are more than a few ways of doing this, even for a very new manager.

Actions taken

For example in each session, every member of the team may be asked to come up with one thing that they feel is working well, one thing that they do not think is working, and one suggestion. The suggestion will usually be some proposal on how to solve the “bad” that the person brings forth.

The entire group then has a chance to discuss all of the different ways that the “bad” can be addressed. Any processes that are broken will be brought to light immediately. Nobody knows when something is missing like the team themselves.

You can schedule regular checkpoints throughout each sprint to prevent problems from getting too far ahead of the team’s ability to manage them.

My current team’s work is very data-driven; they make every decision according to what we see. We wanted to get an idea of how good we were at accurately predicting what we can do over the course of a sprint, so we did a little bit of homework.

You can begin by figuring out how many days each member of the team has available during the sprint, taking any off-days, travel days, or days that are typically stacked with meetings into account. Once you’ve got the total number of working man-days at your disposal, you can calculate the total number of complexity points that can be taken on in a single sprint.

Forty working days across your entire team may correspond to ten points of work or thirty; it all depends on how the points are defined. If you plan to tackle thirty points in a single sprint but are only able to handle twenty, ten of those thirty points are in dispute. Capturing this data over multiple sprints will allow you to start predicting the accuracy of your team’s grasp on the exercise.

If after four or five sprints you find that thirty is just too much, reducing this number may help you plan your weeks more effectively. The same goes for the opposite scenario. If you plan for thirty and consistently are able to take on forty, your team is ready to take on more.

This is a really great way of doing things; it is data-driven and it prevents people from becoming over-encumbered. You do not want to be this dictatorial person. As a leader, you need to have a nuanced understanding of what it actually takes for the team to achieve what they set out to do.

Lessons learned

• Engineers respond well to a data-driven approach to mapping out the road ahead. It is one great way of getting your sprint-planning routine off of the ground if Agile is new to your company. The data is there to prove you right or to prove you wrong. Be open-minded with the data in front of you. Trust it to lead the way.
• Carrying this way of thinking through to each quarter allows you to extrapolate this data in order to ascertain the feasible OKRs that the team can take on. If a PM asks if a feature can be released by the end of the quarter, you can use these tools to tell them exactly how long what they want will take. The velocity of the team, the nature of the work, and many other factors will all play into this final estimate.
• As a former engineer, I feel as though I have enough of a background to make some of those necessary assumptions while planning this work for others. For any manager, measuring things will always be very important. This removes the sense of hierarchy that may result when decisions are being passed down from above without any input from those on the ground.