Skip to content

Blog /Teamwork /

Daily Goals and Software Teams: Why and How

February 22nd 2016

by Henry Poydar

in Teamwork

One thing. Per day.

People who make stuff, like programmers, writers, and designers, are limited to working on one or two intellectual tasks per day. That’s it.

You might hear otherwise from developers on your team, compounding the difficulties of figuring out when you might be able to ship software, but that’s the simple truth. One thing (maybe two, or maybe a fraction of a thing) per day.

A “thing” is essentially any exercise that requires mental setup, then translating from an abstracted notion to an executed concept, and finally testing against acceptance criteria. In other words, building part or whole of a software product feature.

This is because programmers and other creative thinkers have a finite amount of energy to apply to these things on a daily basis, and building things is more about thinking and abstraction rather than typing lines of code.

An example: favoriting an item

Favoriting something

Here’s an example to illustrate the point: let’s say a web developer is tasked with building a feature for favoriting comments to published articles within some sort of blogging application. Seems small, right? But this kind of thing will usually involve steps like this:

  • Pull down latest tested source, update any changed dependencies, and fork it for the feature
  • Layout (on a whiteboard/spreadsheet/whatever) a domain model for how data will live and be named within the application (how a comment is marked as a favorite)
  • Translate the domain model to database tables and columns, depending on the general way data is persisted in the app, and build a script to update the existing database
  • Build in any constraints (are favorites limited by user?)
  • Map the new data storage to triggers in the app depending on what the design calls for (the favorite icon is clicked from an article view, the icon is tapped from the responsive mobile view, an API call is made)
  • Modularize the event of favoriting so the code for it only exists in one place
  • Hook up the app triggers from the user interface to the new module
  • Account for edge cases (perhaps the user gets a special message on their first favorite?)
  • Make sure you’re busting caches (or not!) properly
  • Unit test the module, unit test the data model, write a few automated integration tests that cover the various permutations of the flow across different devices
  • Demo the feature to the designers or product owner
  • Go back and fix stuff

That’s going to take a day or two. It’s also going to require quite a bit of mental energy. That’s because the domain model of favoriting as envisioned AND the domain model of the app need to form a sort of Venn diagram in the developers head in order to facilitate all of the little decisions made as they write code in the steps above.

Developer Venn diagram progression

Even for small greenfield features, your developer is going to be too drained to gear up again on the same day for something else other than small tasks like emails, typo-ish bug fixes and snacks.

So you can forget assigning “hours” to feature tasks. And sure, you can say “spend half your day on this and half your day on that” to try and squeeze another thing in a day, but the mental spin-up of those Venn diagrams in your developer’s head is costly in terms of their daily energy. It’s way more efficient to limit the number of times that happens, if you can.

One or two things. Per day.

So now what? Daily goals!

What to do with the one or two things rule as a product owner or software team lead? Daily goal setting.

Assign features to developers as you normally would (planning poker, Kanban, Scrum coordination, etc), but let the team take it from there by coming up with their own daily goals.

Each day, have each team member write out–to you and the rest of the team–the one or two things they will tackle that day as a goal or two. Short and sweet. Then the next day, have them each declare, again in a way that’s transparent to the team, if they met those goals or not, along with new goals for that day.

Emphasize that it’s absolutely okay to miss goals. The idea is to get better at realistically setting goals, so missing them is the way to do that.

Rinse and repeat.

One daily thing checkbox

After a few days of this, you’re going to notice some things:

  • People like meeting goals and checking them off as met. It’s an incentive to do stuff and to be better at goal setting.
  • Developers will get better at estimating by understanding their own working velocity and ability to tackle “things”.
  • You’ll get a better sense of each developer’s velocity, and that will help you with scoping and estimation.
  • Human connections build trust. Being a little vulnerable by sharing daily goals (and emphasizing that it’s ok to miss) will help your teammates make those connections with each other.
  • Big project goals and wins and are made of lots of small ones, and meeting daily goals are a great set of small wins your team can celebrate together.
  • Stated daily goals, in real human words and in one place, cut right to the heart of what’s going on with your team. Inferring as much from from ticket numbers, pull requests, email/chat threads and all of the other project management artifacts is hard.

There’s an app for that

Not coincidentally, we’ve built an app for this, Status Hero.

Status Hero is actually not really an “app” in the conventional sense, since it runs over all of your conventional communication tools like Slack, text messaging and email, and doesn’t require downloads, invites or even logins for your team.

Every day, your team members take 1-2 minutes to respond to a bot, text message or email, and set a daily goal or two. The app links the previous day’s goals and presents a giant checkbox for marking those goals as complete.

The result is snapshot of your team’s progress, delivered via bot or email to your doorstep:

Status Hero screenshot

Status Hero allows you to ditch your daily standup (perfect for remote teams) while adding goal tracking, with all of the benefits outlined above.

Recap (tl;dr)

  • Developers are good for 1-2 meaty programming tasks per day
  • Use self-set daily goals to track those 1 or 2 things
  • Tracking daily goals across the team pays big dividends
  • There’s an app to automate daily goal tracking for software teams: Status Hero

More in Teamwork

Subscribe to The Steady Beat

A weekly-ish round-up of hand-picked articles and resources for people who make software products: designers, engineers, product managers, and organizational leaders.

Subscribe now