Tag: project management

Health Checks: Tasks

Health Checks: Tasks

This category looks at Tracker Item volume, status, and history.

Note: Because a Project can contain multiple Trackers (for, e.g., Development Tasks, Customer Support, Server List, and whatever else you need), each check can generate multiple fail or warning messages.

Long-Running Tasks

Definition: The number of tasks that have been open longer than 90 days, with some activity in the past seven days.

What it means: Tasks that linger for weeks or months clog your Standup, Burndown, and planning process. These tasks can also be a quiet drain on team productivity – making slow progress on a task requires way more task-switching than small, focused ones.

How to fix? Look at each long-running task, and ask these questions:

  1. Is this still worth doing? Close it if it’s not valuable.
  2. Is the task too vague? Clarifying the goal can make it easier to reach.
  3. Is the task too broad? Create sub-tasks that can go faster.

Recycled Tasks

Definition: The number of tasks that are currently open, but have been closed more than twice in the past.

What it means: Much like Long-Running Tasks, Recycled Tasks get in the way of good planning and tracking. They’re usually re-opened unexpectedly, usually because “done” is poorly-defined or regularly gets “un-done” somehow.

How to fix? Much like Long-Running Tasks, look at each Recycled Task and see if it should be refined in scope or killed permanently. Some tasks that keep coming back have an underlying technical or business-process cause – attack that instead of just changing the band-aid over and over again.

Stale Tasks

Definition: Tasks that are currently open and assigned or in a Sprint, but with no activity in the past 30 days.

What it means: Assigning a task or adding it to a Sprint represents a commitment to completing that Task. Tasks that sit for weeks with no progress are taking up attention and Story Points from other priorities.

How to fix? For each Stale Task, do one of the following:

  • Bump the priority
  • Re-assign to someone with bandwidth
  • Un-assign, and come back to it later

Health Checks: Commits

Health Checks: Commits

This category of health checks focuses on the code you check into your GForge Next project, how it relates to task management, team and file sizes.

Commits Per Tracker Item

Definition: The number of separate commits associated to each Tracker Item in your project. Only commits created in the last 90 days are used, so the trends will change over time.

What it means: Having too many commits makes it harder to understand the associated Tracker Item’s history later on. It can also skew Sprint, Burndown, and Release metrics to look bigger or smaller than they really are.

How to fix? Although you can add or remove associations between a commit and a Tracker Item, it’s better to look forward than try to change history. When planning a Sprint or Release, consider the size of each Tracker Item, and break them down into smaller tasks that might affect fewer files, or involve fewer iterations for each TI.

Commits with Tracker Items

Definition: The percentage of commits in the last 90 days that are associated (or not) to a Tracker Item. Also checks for commits that are tied to more than on TI.

What it means: Pushing commits without an associated task is an easy way to mess up your code base over time. It’s also bad for team collaboration and Sprint and/or Release tracking.

How to fix? To fix existing commits, you can create Tracker Items, and associate them using the SCM Commits listing. Click a commit and use the “Tracker Item Associations” section at the bottom of the commit details view.

You can (and should) also fix the process for pushing commits to your project:

  1. Go to the Project Admin SCM tab, and choose “Require” for the “Associate Tracker Items” option.
  2. You might also check the “Restrict Tracker Item Associations” setting, depending on whether you want to allow associations between commits in this project and Tracker Items from other projects.
  3. Usually, this setting should be “Yes” to keep it to the current project.

Committers

Definition: The number of users with commits in the last 90 days, and the proportion of all commits made by each user.

What it means: For smaller projects (with only one or two contributors) this check won’t mean much. For full-sized Agile teams (4-5 contributors) or larger, traditional teams (10 or more contributors), this check can help you understand if work is balanced properly between team members.

How to fix? If you’re not using Tracker Items (and requiring that commits tie to them), then you should start right away. Having a specific task should be required in order to make code changes anyway, and an official task list lets the Product Owner, Scrum Master, or even the team itself to balance tasks among contributors by size, functional area and dependencies. Proper task balancing will lead to balanced commits from the team.

Files Per Commit

Definition: The number of files changed (or added, or removed) by each commit. Only commits created in the last 90 days are used, so the trends will change over time.

What it means: In general, commits should touch less than ten files. Large commits (many files and/or many lines of code) are harder to review, harder to understand later, and more likely to cause merge conflicts with other commits.

How to fix? This is another one where what’s done is done. Going forward, make sure that the team is doing proper analysis on task sizes during planning, and on the changes to be made when working each task. If a specific task requires changing many files, try to find a way to iterate on it, changing a few files in one commit, reviewing/merging that commit, then moving on to the next set of files.

Of course, sometimes you’ll just need to bite the bullet – a breaking change in a dependency/library, an urgent security fix, etc. But those hefty commits should be the exception and not the rule.