wilsonross / user-capacity

Estimates how much time a developer will be able to spend on tickets when planning a sprint

About

User Capacity is a tool for evaluating how much time a developer will be able to spend on tickets during a sprint. It gathers data from Everhour, and a calendar feeds to determine this figure and sends it to Jira.

Installation

git clone https://github.com/rossw19/usercapacity.git
cd usercapacity
go get ./...
go build cmd/capacity.go

Configuration

The tool uses a yaml configuration file to determine the parameters for the application (similar to a dot-env). I have chosen this design decision so that key-value pairs can be added, along with user mapping between Everhour, Jira and the calendar feed. To start, rename the sample configuration file and fill in the values for API keys and API URLs. Some values are slightly ambiguous and explained below.

Key	Description
api_url_everhour	The base URL for the Everhour API
api_url_jira	The base URL for the Jira API
api_url_ics	The base URL for the calendar feed
api_email_jira	The email address for the Jira API authentication
api_auth_everhour	The API key for the Everhour API
api_auth_jira	The API key for the Jira API
api_version_everhour	The version of the Everhour API
logging	Enables logging to var/log/debug.log in root directory of application
application_context_calendar_days	The number of days a sprint takes to complete, including non-working days
application_context_working_days	The number of days a sprint takes to complete, excluding non-working days
application_context_average_over	The number of sprints the average is calculated over

User Mapping

Additionally, there is a user mapping configuration between each service. It contains the user identities from each feed. The calendar feed is mapped by name, as the service I use does not provide an employee ID.

Key	Description
everhourId	The user ID for the Everhour API
jiraId	The user ID for the Jira API
name	The name of the user in the calendar feed

Usage

After the application has been configured and built, it can be run by executing the file created when building the application. Additionally, a cron can be made to fire the application when required. Running the program during a workday when time is tracked will yield less accurate results.

Contact

Ross Wilson - [email protected]