Typical daily stand-up meeting for Intervals development

In this post…

When working with your team, has a task taken longer than expected? Everyone feels it, yet hesitates to say anything because no one wants anyone to feel bad that it’s taking so long? Upon trying to dig in, explanations are unclear and discussions around it start to feel more and more awkward and to be honest, quite confusing?

Communication can be hard. And when it’s hard, people stop talking. That isn’t good when you need to be working together as a team and getting things done.

Communication is key for us humans as we work together, and tracking time brings data into our conversations about our work, making us more efficient when we communicate.

Let’s look at an example of a team interaction when they track time vs when they do not. This is an example of an agile software development team that uses Scrum for their software development process and have a Daily Stand-up (aka Daily Scrum) to kick off the day.

First, let’s observe the Stand-up when the team is not tracking time

The team is going around the circle and giving a status on what they are working on. It is now Developer Jessie’s turn.

Jessie says:

I started working on task ‘X’ that I picked up from the queue. I worked on that yesterday and will continue working on it today.

Everyone nods and continues around the circle. Unbeknownst to Product Owner Bill, he just made some assumptions from Jessie’s update.

He thinks to himself:

Oh cool, she worked on it yesterday and today…it was estimated to take 2 days, so that should most likely be completed tomorrow (about 2 days worth of work).

Now, let’s observe the stand-up when they are tracking time

The team is looking at their time tracking tool as they go around to give their status.

Jessie says:

Yesterday I spent an hour understanding the feature itself (1 hour = Learning).  I was not very familiar with this area, so I was doing some research to get familiar with the feature and how it would tie into existing functionality. Then I spent a couple more hours starting to look at the code (2 hours = Code Research). I needed to chat with Mike, the original developer of the code in that area, as I had some questions. Mike and I came up with a couple possible ways to attack the problem, so I’m going to look at both, sync back up with him and then pick an approach. I’m estimating that will take me about 3 hours total, including syncing back up with Mike.

Next day, Jessie reports on the status of the task:

Yesterday I looked into the code and have a couple approaches, but Mike wasn’t available, so I paired with Jason on his task. Mike and I have time scheduled today to get together to discuss. My estimated time is still the same, 3 hours will be about right. 2 hours doing my research yesterday and about 1 hour today, to chat with Mike. We estimated total time on this task to be 15 hours, but after digging in and talking with Mike, it feels like this is going to be more like a 25 hour task.

Advantages for teams tracking time

Clearer communication about the work being done

Conversations go from general talk about working on the task, to the specific type of work being done. e.g. researching, learning, actually writing code, etc. Clearly, Jessie’s update in the second scenario was much more informative to the team, preventing Product Owner Bill from assuming the task was much further along than it actually was.

Blockers are more quickly identified

In the situation above, Mike (the original developer) was a blocker and slowed down progress on the task. This was brought to light at their meeting and could possibly be something that needs to be addressed in the future if it becomes an ongoing problem. Maybe someone on the team knows another developer that could help out since Mike’s time was limited. In the first scenario, no one would be able to make that suggestion because they would have no idea that Jessie was blocked by Mike’s unavailability.

Team uses facts and real data to make decisions

Instead of making assumptions along the way about when the task will be complete, the entire team is on the same page about the progress of the task. This allows the team to pivot, if needed, based on real data and make educated decisions. Most tasks are never fleshed out completely at the start…there are always some unknowns that pop up. As the team learns more about the task, they remain better connected, allowing them to be more effective in their communication, which is crucial when making tough & critical business decisions.

Opportunities to learn from estimates that are off

Reflecting on this type of data is VERY valuable. There are so many learning opportunities when discussing why tasks took longer than expected. Teams can have effective discussions on how to get better because they are fully aware of the type of work completed and the details in order to better analyze the situation. Having this data as a talking point also makes the discussion less personal. You’re analyzing data, not people.

Hök Nik, an Intervals customer said it perfectly:

“With Intervals there is less intuit required, because it takes personality and emotion out of the equation. It’s really hard to argue with the data.”

Over time, the first example cannot only breed anxiety, feelings of frustration, and lack of satisfaction in your daily work, it can prevent teams from becoming stronger and more productive.

Communication is hard…with all the emotions, personalities, differences in backgrounds that come along with the humans that are communicating, using facts to drive our conversations, actually makes communication more rewarding and propels our productivity to new heights.