Refreshing an Internal Tool

To keep the whole team on the same page about progress, we built an internal tool we (creatively) called the "Sprint Tool". This tool aggregates some key information from other systems via their APIs:

• Planned allocations from our resourcing system
• Time off from our HR system
• Actual time logged to projects from our time tracking system

This combination gives a holistic picture of how each team member has progressed against each project's allocations at any given time. It's a read-only lens into canonical data from elsewhere, but it provides specific insights that would be difficult to see otherwise.

The Sprint Tool plays a key role for our teams in a variety of contexts:

• It’s a visual aid each morning during our stand up meeting to review allocations and progress across the team.
• It’s a planning aid to help designers and developers figure out what to work on each morning and keep steady progress on all projects throughout the sprint
• It’s a budget and resourcing aid for project managers to check in on remaining allocations and hours burned on their projects.

However useful it is, it’s still a private tool for a very small audience, which meant we weren’t as driven to give it the kind of love and attention we put into the work we do for our clients. It was functional, reliable, and served us well for 7+ years.

Over those years, while the Sprint Tool remained steadfast, Happy Cog continued to grow. We substantially expanded our design practice, hired dozens of new team members, and enjoyed all of the new functionality and tooling afforded by the steady progress of the web.

At the end of 2022, we also made a significant change to our sprint cadence. Rather than 2-week intervals, each calendar month now contains two sprints: one from the 1st-15th, and the second from the 16th to the end of the month. This immensely simplifies resourcing for our monthly retainer engagements, while keeping the same rough granularity we had with two-week sprints.

The cadence change was the perfect catalyst to give the Sprint Tool a little attention. Everyone agreed that a fresh coat of paint would be nice, but more interesting ideas started to flow when the tool was a little more top-of-mind. A collective focus, and direct team feedback were the key drivers in deciding what would be the most impactful changes we could make to the tool we use so regularly.

That transition from feedback to features is something we tackle regularly in our client work, so it was fun to have our team play both sides and decide what the tool would become. Here’s a few examples of how we made that transition and transformed this tool.

“So when does the sprint end?”

With the previous 2-week cadence, sprints always started on the same day of the week, and had the same number of days. The new twice-monthly cadence provides a slew of benefits, but makes it harder to know how many days are left in the sprint without looking at a calendar.

So let’s add a calendar! — The new tool plots the current sprint on a small monthly calendar and highlights today’s date, so it’s much easier to see spatially how many work days are left. The tool also displays the specific sprint dates and a count of how many working days are included for easy reference.

“How many hours should I have planned?”

With the previous 2-week cadence, sprints always had the same number of days, and so had the same number of resourced hours. That made it easy to see at a glance if a team member was over- or under-resourced. The new twice-monthly cadence means each sprint could have anywhere from 9-12 days, so the total allocation will vary between sprints, making it harder to know if a team member’s allocations are off.

So let’s make it more obvious! — The new tool knows what the sprint dates are and calculates the expected hours for the given sprint. When someone’s allocations don’t match, the tool now bubbles up a small alert below their name, which makes it much more obvious that allocations need to be adjusted.

“What project might be able to spare a few hours?”

During a sprint, project managers may need to adjust a team member’s allocations to cover urgent requests, tasks taking longer than anticipated, or impending deadlines. The previous tool sorted projects for each team member alphabetically, which made it very easy to find a specific project you were looking for, but harder to get a sense of which projects had big allocations versus small allocations.

So let’s sort by allocation! — The new tool sorts projects by largest allocation, which gives a much better overview of a team member’s relative priorities. And since team members always have a small number of projects, it’s still easy to scan the small list if you’re looking for something specific.

“Oh yeah, I’m OOO next week”

The Sprint Tool has always included time off, but historically presented it just like any other project — a team member would be “resourced” for a certain number of hours on an out of office “project”, so that the total allocation sums would match up. This makes sense technically, but didn’t make it easy to tell who had time off in the near future.

So let’s make it easier to notice! — The new tool keeps time off in the allocations table, but always sorts it to the bottom of the list, and displays it using a smaller, more subtle styling than regular projects. Since we already added a place to bubble up relevant info like over- or under-resourcing, the new tool also bubbles up OOO time making it much easier to find, and formats it using “days” rather than “hours” which make it much easier to understand.

“What’s project 197546?”

Some data in the Sprint Tool needs to be augmented manually to connect the different systems it’s pulling from. For example, we manually set some unique identifiers to connect the “project” in our time tracker to the same “project” in our resourcing system so logged time can be matched against allocations. Every once in a while that connection hasn’t been set, so a project is listed in the tool using a short number without any additional details like the client or project name. It’s a quick fix for a project manager, but previously could go unnoticed for a little while because these unmapped projects blended in with the rest of the projects in the list.

So let’s highlight them! — The new tool detects the missing info, and highlights the unmapped project both in the allocations table and as a small bubbled-up alert. This makes it a lot easier for project managers to notice when there’s an unmapped project so it can be corrected.

“It’s so busy looking, especially at the end of the sprint”

In an effort to help team members notice when they were approaching their allocations, the previous tool highlighted each project row as time was logged. Rows would turn yellow at 80%, orange at 90%, and red after 100%. Team members always strive to use their full allocation for each project, so as the sprint progressed, the whole tool naturally turned into a busy stack of yellow, orange, and red.

So let’s tame it down! — The ultimate driver behind the thresholds was to highlight when team members exceeded their allocations, which might require intervention from the project management team to rebalance priorities, so we decided to just focus on highlighting overages with color. But, an ancillary benefit of the other threshold colors was that it gave the sense of progress as the sprint continued. The new tool tries to bring that sense of movement back by displaying logged time as a progress bar in the background of the remaining allocation column. The bar is subtle so it doesn’t distract, but visibly changes over time, and when it exceeds 100% it turns red to highlight the overage.

“It’s so bright”

A lot of the other software we use at Happy Cog has added support for a dark mode that’s a little easier on the eyes, especially for folks who use dark mode everywhere it’s available. Some informal polling of the team showed a split decision about who wanted a dark palette, and who liked it a bit brighter.

So let’s add dark mode! — There’s not much markup in the tool at all, so adding a dark mode provides a huge benefit for the folks that want it without much development effort.

“Don’t forget, we’re closed on Monday for the holiday”

Happy Cog is closed for several holidays throughout the year. This time is accounted for in our resourcing allocations, but previously the Sprint Tool simply adjusted the total allocation time for every team member. In other words, holidays were accounted for, but invisibly.

So let’s put them on the calendar! — Since we added a spatial reference for how the sprint falls in the calendar month, holidays should be included there too. The new tool also bubbles up the name of the holiday alongside the number of working days as a quick reference, which helps keep holidays in mind as we begin the workday.

---

We launched the new Sprint Tool in July 2023, and the feedback after months of use has been resoundingly positive. Allocation discrepancies and unmapped projects are being addressed more quickly, holidays and time off come up more often during standup, and the tool that was once stark and utilitarian now feels a little more friendly and helpful, just like the people who use it.

Internal tools don’t always get the same level of attention as things that are more widely available, but sometimes it’s worth taking a closer look to see if there’s an opportunity to make them a little more valuable than they were before. Great tools can work well for years to come, but they don’t exist in a vacuum, so seizing opportunities to re-evaluate and make improvements — no matter how small — can end up making a big difference.

Back to Top