I'm struggling with how to keep track of what myself and people on my team actually do each day. I get a good broad picture by going over completed cards each week and stand-ups help a bit, but I feel like I don't have a good handle on the day-to-day workings of my team. Cards will stay in progress for days on end without an update at the daily stand-up, and some engineers are my team aren't the most communicative.

I've thought about implementing some sort of daily record that everyone fills out (via a mailing list or a shared google doc) but this seems fairly cumbersome and manual.

Monitoring GitHub activity does an ok job but can be a little bit overwhelming with how many emails it sends out everyday. I've thought about trying to build a digest system for it, but don't have the time to spare.

What strategies have you implemented to stay on top of what your team is doing everyday so that you can measure work on "in progress" tasks?

  • 5
    This be better asked over at workplace.se.
    – mattnz
    Sep 8, 2014 at 23:15
  • 39
    @mattnz - I don't know. The answer will vary pretty significantly between a programmer and a basketball player and a mailman.
    – Telastyn
    Sep 8, 2014 at 23:46
  • 2
    What types of questions should I avoid asking?
    – user22815
    Sep 8, 2014 at 23:49
  • 17
    That should be covered off in the daily stand-up's. Where I work, each of us devs state what we are currently working on, and what we intend to work on tomorrow. The trick to this is participants must not feel like they are being 'tracked', if you feel a dev may be lagging, DO NOT bring it up in the standup, instead keep that conversation private.
    – JuStDaN
    Sep 9, 2014 at 1:09
  • 5
    @mattnz - Okay, replace the examples with Accountant and Lawyer. Or Doctor and Politician. Or Plumber and Secretary. In the end, there's no single "how to track what a team of professionals is doing" answer because different professions need different approaches - and thus not a great fit for the Workplace.
    – Telastyn
    Sep 9, 2014 at 2:33

9 Answers 9


I talk to them.

Technology cannot solve social problems. You have short morning standups. What did you do yesterday? What will you do today? Any impediments?

If something sounds fishy (or I'm curious), I stop and ask questions: "You were working on XYZ yesterday, how'd that turn out?". This forces people to pay attention, and to actually know what's going on. It also keeps you the team lead in the loop (and paying attention, and knowing actually what's going on). This needs to be on time, and short (10 minutes max). Anything else and people won't "shelve" work. They'll stop and wait for the standup and then take time to get started again. Some will do that anyways, but it's largely unavoidable.

Then I stop by everyone's desk in the afternoon. Not every afternoon (though it might be more than every afternoon for new people), not at the same time, but around the same time (so it's both informal, and regular). "Any problems? Any impediments?"

You'll be surprised how often you'll encounter problems when people are one on one.

If people have no problems, great; get back to work. If they don't have problems all week? Problem. You're not challenging them enough, or they're not opening up. Ask how XYZ (that they mentioned in standup) is going. Make them explain things.

This isn't micromanagement. You're not telling them how to do their jobs. You're not babysitting them. You're there to remove impediments from their day to day life. You need information to do that. As long as you keep your team out of meetings, and project managers out of their cubes, then one person stopping by to help once a day isn't going to cause them grief. But all these interactions need to come from the "I am here to help you" vein.

Another thing I will do is review changesets (by myself, informally). I can then see how frequently people check in, how large their changesets are, how that matches what they reported, how often they re-do things, how many bugfixes they have, and so on. A work item changing status to "done" is nearly meaningless. Look at the code. Does it seem done?

note: One extremely serious side point: how big is your team? Is it more than 7 people? Of course you won't be able to keep track of everything going on if your team is too big.

  • 31
    +1 Teams that do not communicate are not teams, and do not get work done.
    – user22815
    Sep 8, 2014 at 23:57
  • 33
    Wow. Revolutionary! Do I have to actually talk? Or can I have an app for that?
    – andy256
    Sep 9, 2014 at 0:57
  • 1
    ...how many bugfixes they have... Sep 9, 2014 at 7:41
  • 7
    @Snowman:Your comment is nothing but a false platitude. I've been on many, many different kinds of teams over the years and have not seen your platitude be a key factor into the success or failure of any of those teams. Some teams have been extremely efficient and successful with nose-down, get it done, don't bother me people (actually the most successful teams I've been on have been like this). While other teams have been utter failures with communication up the ying-yang.
    – Dunk
    Sep 9, 2014 at 13:09
  • 5
    RE: "If they don't have problems all week? Problem." -- It may just be too that you arn't the right person to solve the problem. Maybe another dev, the internet or something else is already working to remove the impediment. Sep 9, 2014 at 13:54

Don't micro-manage your developers!

Productive software development requires long stretches of concentrated mental effort. It's not realistic to expect them to produce constant output. If you begin measuring them on a daily basis, they will restructure their work so that they always produce some discernible artifacts for you to see each day. That may or may not have a positive impact on your software quality. It will almost certainly have a negative impact on your developers' efficiency.

  • 28
    Unfortunately I only have one upvote for this! " If you begin measuring them on a daily basis, they will restructure their work so that they always produce some discernible artifacts for you to see each day.": For complex tasks, even a weekly checkpoint (one-week sprints) can have this effect: you end up working to produce a visible result instead of focusing on solving the real problems.
    – Giorgio
    Sep 8, 2014 at 23:52
  • 4
    Come crunch time, I spend the first day picking the low-hanging fruit to play the numbers game. Look how much we got done in one day! I save a little so other days I can knock out some requirements/feedback first thing in the morning then spend the rest of the day working on the important stuff.
    – user22815
    Sep 8, 2014 at 23:57
  • 6
    One might argue that work without a discernible artifact isn't useful to your clients, and thus to your company </devil's advocate>
    – Telastyn
    Sep 9, 2014 at 3:01
  • 14
    @Telastyn: Clearly you need discernible artifacts to be useful to your clients. The point is how often you and your client need them. There is no general rule but monitoring the development process too closely can disturb the process itself, slow it down and reduce the quality of the results. As a provocative example, when you walk, do you check that you are going in the right direction after every step?
    – Giorgio
    Sep 9, 2014 at 6:06
  • 3
    I agree with the content of this, but I disagree that it's an answer to the question. I do track daily progress, but managing is an interactive process. That interaction I typically reserve for the end of the sprint. Even if you manage on high-level statistics, those statistics are made by gathering individual data points. They don't magically appear on my desk.
    – MSalters
    Sep 9, 2014 at 20:37

As Robert Harvey suggests, don't micro manage your team. Give the team some prioritized tasks with concrete business value and let your team figure out best how to deliver this business value.

If the team delivers business value, then you should be happy. How they go about making sure that they deliver the requested features should be up to them.


Cards will stay in progress for days on end without an update at the daily stand-up

This could indicate that there is a deficiency in the process.

It could be the team that is not really functioning as a team, and not stepping in to help each other out when they are stuck. It could also be the communication with the business. The tasks are too big, so it becomes difficult to figure out what is needed. Specifications are not clear.

It could also be that there is no real problem at all. Maybe the team just works fine with cards representing major pieces of work that takes days to complete, and maybe the team is working fine to achieve this.

I think that it is valid to use the retrospective as a platform for expressing your concern. Sometimes it's a good thing to receive observations from the outside.

But let the team figure out if there is a problem, and what is the cause of this. And be ready to accept that perhaps you need to adjust the way that tasks are delivered to the team.

Remember that the daily stand up is a tool for the team to help them organize the work; it is NOT a tool for managers to keep track on what the team is doing.


'Push messaging' not 'pull messaging'

A developer will often get to one of the following states that matter to you:

  1. Yaaay, I did X !
  2. I'm working on X, but it looks like it will take a prolonged time...
  3. I'm stuck on problem Y, am researching it but might need advice;
  4. I'm blocked because I'm waiting for A,B and C.

Ideally, you want to have a reasonably up-to-date information on these statuses without disrupting actual productivity. Constant "Are we there yet?" is counterproductive, but it may be that you can do something useful for states 2-4, so you need to get informed about them.

What will work is a culture of 'push messaging', preferably in an automated way. You may not need to look at the whole commit-log, but you can make a "dashboard" where you see the latest commit or the latest solved ticket (for bugs or features) of every teammember. For the rest of the situations, you can get them to e-mail you proactively with such updates (hopefully they are more rare than commits) or go and ask them if you're not seeing continuous progress on whatever dashboard - if you have an internal agreement that getting stuck needs to be raised (it might be that some feature isn't needed if it turns out that it costs 80 hours not 8 hours), then either they'll keep you up to date or get bothered by you.

Alternatively, you may make a culture of something like https://idonethis.com/ daily reports going out to the whole team - this will ensure that others are on the same page as well.

  • 1
    We (tried to) use idonethis for about 2 months, it didn't work out - because you had to actually take a moment to go somewhere else, and only to update your status, most of us forgot it existed
    – Izkata
    Sep 9, 2014 at 15:40
  • I certainly use our problem tracking systems and change management systems when compiling midyear/endyear reports on what I've been doing, and we use the Jazz "dashboard" to manage activity as departments and on the projects as a whole. Scrum meetings communicate what we're working on at the moment but don't maintain detailed history. I've found it also useful, for my own sake, to throw together a little commandline tool that lets me quickly dash off a timestamped one-line note to myself; that's useful for recording activity and detail not easily visible thru the other systems.
    – keshlam
    Sep 10, 2014 at 1:49
  • @Izkata I feel the same way about the time management software I'm using at my current place, I eventually set up a reminder to trigger at 4PM(for days I start early) and 6PM(for days I start late) every day to remind me to update the system. So far I've forgotten far less often to update the system. Might be worth considering if you want to continue using such a system.
    – scragar
    Sep 11, 2014 at 17:21

An alternative to some of the other answers (communication focused) is that perhaps the tasks on your note cards can be broken up into smaller pieces which you would then be able to get feedback on sooner.

With smaller pieces the team feels like they are accomplishing something every day which should reflect in the stand-up.

The drawback is these separate cards will likely rely a lot on each other. A team which is able to communicate very easily with each other is beneficial here, or pieces may not combine as well as they should. You may also need to hold some of the cards back if you need certain things done first.

That being said, people will still get stuck or find out a task is much more challenging than they, or you, anticipated from time to time. This is why it is still helpful to discuss issues openly in the stand-up where others can offer advice without judging the person having troubles.

To answer the issue of micro-management as some of the other answers have brought up: even though people will accomplish small tasks each day it will take a broader view of their accomplished work to get a sense how much each person is actually getting done, rather than judging them by their daily accomplishments.

I suggest this because I work on a team of 8, where communication is very easy and people are very approachable. We are given tasks that are never expected to take longer than two days worth of work. Sometimes these tasks are closely related and we need to keep each other updated on how we each go about our own piece. We are each responsible for reporting what we've accomplished every two weeks to our manager.

After reading the question again, I realize you may be asking this as a team member, not as a leader, and so you may not have control over your tasks.

  1. You could suggest to your leader to break up the tasks more
  2. If your work is getting blocked or depends on work by another team member, feel free to check with them on it and take a different task if you need to.
  • 1
    Breaking things up into a hierarchy of smaller pieces and tracking dependencies between them is one of the things Jazz/RTC is good at.
    – keshlam
    Sep 10, 2014 at 1:50

First of all you need to analyze yourself in terms of your time and skills. If you are a technical person with some previous hands-on experience things may different from those in case you are just a manager (not with strong technical knowledge on what your developers are actually working on) who only needs to make sure that deadlines are met.

The common point in both the cases is that you need to be able to facilitate your team and create a feeling that you trust them. You are not judging their performance but are trying to be empathetic and helpful in making their experience fun and easy.

Now assume that you are just a manager as i said above, in that case even if some developer is really facing some serious development related problem you may not be able to help her/him. The actual problem can be time consuming and will demand concentration as well. Further assuming that the developer is really sincere to his/her job and paying full time (even extra time ) to resolving that problem but unfortunately still not able to solve it. And in such a situation (when your are not even able to understand the problem fully) you keep on asking about the issue by taking progress everyday and even informally twice a day. The result would be extreme frustration and disturbance for the developer. Whether its an app for gathering daily progress or its just daily standup meeting both can be frustrating.

On the other hand, keeping all the other factors same, just assume that you have strong technical background and have worked on the same technologies in the past. In this case, taking daily progress or having standup meetings is really helpful. Developers will surely trust you and your expertise and will be comfortable in discussing the big challenge they are facing. You'll provide some suggestions which can be helpful or even if they are not directly helpful they'll help in providing some alternative approaches.

However, in any case daily standup meetings must create a sense of you being a team member not a head/lead/manager. Unless your team members consider you at the same level as they are, they won't be able to communicate their concerns/suggestions/problems/feedback etc.
Another point to be considered is the size of your team and the time you have for managing them, before thinking of using some automated progress tracking software or increasing your interaction. You need to make sure that whatever concerns have been raised by your team, you are able to resolve them asap. A major demotivating factor for a team member is that their concerns/suggestions/feedback is not taken seriously or is not valued. Knowing the daily progress is important but only in case you are fully involved in the team work. If you are involved in some side businesses as well, don't try to interact more with your team. Think of a situation in which your team's response is overwhelming and they are submitting their tasks well before time, raising concerns and queries but you are unable to provide timely feedback and reviews. In such a situation, your influence as a team lead will be greatly reduced


Create and make good use of various IM chat rooms for the various configurations. Some may be broad like @engineers and some may be specific such as @newFeatureA

Consider making daily standup include a review of in-flight tickets.

Use a open environment that supports collaboration and make sure that QE and the primary product owner sit in the middle of the developers. You'll overhear a lot and get an idea from seeing screens around you.

As Robert points out, above all don't be seen to be micro-managing (note the use of 'be seen', i.e. regardless of your actual intent).

Ultimately we track what is accomplished over time and see what our velocity is from that. Focusing on during-the-day progress is counter-productive as people will become demoralized and/or leave.


I'm surprised that no one here has yet mentioned "followed" or "starred" repository messaging built into systems like GitHub or BitBucket.

Our technical stakeholders (project leads, development and support managers) all follow our issue and commit update histories on their relevant projects. We have a small team (15 FTE + contractors), but this seems to work for us to

No one is measured on any of these things, but in addition to weekly status reports from the PM's, this gives a daily view into the project to at least keep everyone aware of what areas are being worked on so no one goes without visibility.

It's also helped to increase transparency across developers and contractors and our business liaisons which helps everyone be accountable to their deliverables schedules.

When combined with RSS feeds associated with specific repositories or across our entire organization, we've been able to limit emails (where wanted) and offer a similar set of data in real-time and in summary via RSS readers. For some users this is Outlook so it's basically email for them, though slightly different, but for other users they use a full-fledged RSS client with all the extra filtering they need to customize it to their exact needs.

We ran into similar concerns about email volume at first, but our end-users came up with the RSS system without the Engineering Org having to do much besides suggest clients for those not using Outlook. Worked for us, again around 20-30 FTE + Contractors throughout the year across multiple offices and time zones. YMMV, obviously.

  • 4
    The OP points out that they follow github digests and it's overwhelming. In my experience, it's a really shallow view into things, which gives a false sense of security.
    – Telastyn
    Sep 9, 2014 at 20:31
  • 2
    That's true enough if you follow all activity on GitHub. To be honest, we use BitBucket for our company and it appears to offer enough fine-grained control over the level of email updates for our small-ish teams. Not sure if GitHub offers the same level of granularity, perhaps someone could compare it to BitBucket if they've used both to help qualify the configuration and team sizes that make it a good fit? Would following only issue updates in GitHub really generate too much activity? It doesn't seem to in BitBucket...and that's enough for our PM's and Leads Sep 9, 2014 at 22:17
  • Added comment about recent developments about using RSS clients (or even Outlook in some cases) to reduce email volume and enable users to self-filter their data, but still keep it as both "real-time" and summary / end of day / end of week as they want. Seems to work well for those who don't want a constant flood of email added to their existing inboxes... Dec 19, 2014 at 23:19

This is a very marginal addition (and it isn't programmer specific), but I've had good success with Asana in recent projects.

For integration with existing online collaboration tools, look no further than Slack. It's built around a chatroom, but it serves as a fairly minimalist hub for other tools including Asana, GitHub, and Bitbucket. It has a decent collection of these "integrations," both pre-made and community-made, using the API that of course allows you to build your own.

  • I'd like to know why this was downvoted. I understand the question asks about "strategies" rather than "tools," but isn't "use a good tool" itself a viable strategy? Sep 10, 2014 at 11:24
  • see How to Answer. "Read the question carefully. What, specifically, is the question asking for? Make sure your answer provides that – or a viable alternative... Brevity is acceptable, but fuller explanations are better..."
    – gnat
    Sep 11, 2014 at 9:14
  • I came here to suggest using Slack. It is an excellent tool to keep track what the team is doing on a day-to-day basis. Which, by the way, is exactly the question. But after looking at this answer and the comments, maybe I just don't understand how programmers.stackexchange.com work (albeit I have lots of reputation points in other sites). Sep 11, 2014 at 17:45
  • @gnat what more would you have wanted out of this answer? I don't see much here that admits a "fuller" explanation Sep 11, 2014 at 20:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.