Create Burndown of Hours Overall and per Task. A burndown chart shows effort expended over time relative to the original estimate. It shows if you’re on track, or perhaps over or under. This provides useful feedback in knowing how the project is progressing for possible repriorizing and/or communicating back with the client. You’ll pull from your Clockify hours to report on burndown overall and per task to generate a burndown chart.
ZenHub Story Points, Burndown, Velocity and Sprints. Story Points are a unitless measure of complexity to apply to issues. The higher the number of Story Points assigned to the issue, the more complex the issue, relative to other issues with a lower number of Story Points. This measure helps in the planning process and subsequent tracking of progress. Sprints are regular, e.g. biweekly, periods over which a set of Issues are assigned for the expectation of fulfilling based on the Story Points associated with Issues and the average number of Story Points accomplished in past Sprints, in other words the Velocity of work completed. Although we don’t have time to go through the cycles of Sprints this quarter, you’re exposed to the concept through the videos from the lecture for possible future application to projects.
You’ll be using the Task assigned to each time entry to generate seperate Burndown plots. To ensure a Task is assigned, visit the https://clockify.me > Go to Tracker > Reports > Detailed, filter by Project and Task “Without task”, Apply Filter. Revisit each of these in your Time Tracker to assign it a Task.
bbest/clockify
Uninstall your existing clockify
package and install a newly improved version bbest/clockify
that I forked from the original and added functions time_entries_all()
and plot_burndown()
.
remove.packages("clockify")
remotes::install_github("bbest/clockify")
Feel free to update any packages with more recent versions if prompted.
In RStudio, you probably need to refresh your Session > Restart R in order to see the newly created functions (time_entries_all()
and plot_burndown()
). Otherwise R will complain that it can’t find those functions, meaning it’s still using the old clockify
, not bbest/clockify
.
time_entries_all()
in your time repoRecall in Lab 2. Time that you first used the Clockify API to fetch your time entries and generate a table of those entries in a time repo under your Github user space. In Step 4.4. Create index.Rmd the suggested R chunk for the index.Rmd
had a section of R code below the # get data
that used the R package clockify’s time_entries()
to fetch the data.
You’ll want to replace all that code with the use of a new function time_entries_all()
that captures all user time entries (based on Step 1.3 Invite Team Members (lead only); not just you, but also your Team members working on the same Project) and includes the Tasks (from Step 1.2 Invite Team Members (lead only)) associated with the time entries.
Expand the code below to show how it should now look. Also update the libraries loaded with librarian::shelf()
.
# get libraries
if (!require(librarian)){
install.packages("librarian")
library(librarian)
}
librarian::shelf(
bbest/clockify,
dplyr, DT, ggplot2,
quiet = TRUE)
# CHANGE THESE VARIABLES!
api_txt <- "~/private/clockify_api-key.txt"
api_txt <- "~/My Drive (ben@ecoquants.com)/private/clockify-api-key_ben@ecoquants.com.txt"
project_name <- "my-rad-team"
# use API key to authenticate
CLOCKIFY_API_KEY <- readLines(api_txt)
set_api_key(CLOCKIFY_API_KEY)
# get data
d_times <- time_entries_all()
# table(d_times$project_name) # confirm project_name
d_times <- d_times %>%
filter(
project_name == !!project_name) %>%
select(
task_name, time_start, duration_hrs,
user_name, description) %>%
arrange(task_name, time_start)
Be sure that you replace above with the appropriate values for and:
api_txt
your API key to Clockify; and
project_name
the exact Project name you input into Clockify. Note there’s a commented out function table(d_times$project_name)
that you can run to tabulate the Projects you’ve entered into Clockify (probably only one).
Note that in the R code chunk above we have only fetched the time entries. Be sure that you are retrieving your time entries by sending d_times
to the R Console, e.g. double click d_times
to highlight the word in the code and per RStudio’s Code > Run Selected Lines, use keyboard shortcuts Command+Return on a Mac or Ctrl+Enter on a PC. Check before and after using filter()
to ensure that your project_name
variable is set with a valid value.
Next, you’ll output those time entries as a Burndown plot and a table per Task and Overall.
plot_burndown()
overall and for each TaskInstead of a single table of entries like last time, let’s now produce a burndown chart for the whole project along with a table of entries nested in a tab set showing each individual Task in neighboring tabs. See 7.6 Put content in tabs | R Markdown Cookbook.
After the code chunk above getting the data, enter a tabset with your Github organization name corresponding to the project (not my example of my-rad-team
):
## my-rad-team {.tabset}
Then add a tab for Overall as a subheading (i.e., level 3 ###
after setting up a level 2 header ##
tabset).
### Overall
And a code chunk below that using the new plot_burndown()
function that uses the ggplot2
library to create a stepped filled area plot and red dashed line for the estimated burn rate.
Then add tabs for each task with a code chunk similar to the Overall tab except for an extra filter()
by Task of the data frame d_times
to get d_task
, i.e. a data frame of time entries specific to that task.
### 1. Import
Repeat for each Task for which you previously estimated hours, per Deliverable in Lab 1. Proposal Step 5 Create Detailed Project Schedule. The chunk for Overall should have an hrs
value that is the sum of all the hrs
value for all the Tasks.
Note that For each of these chunks using the plot_burndown()
function, be sure to swap out with appropriate values for :
beg
end
hrs
hrs
for the Project Overall.Your tabs should look similar (although styled differently from this Distill template) to the following:
xaringanExtra::use_panelset()
How much are you over or under your estimated budget? When did you exceed the budget or stop working on the task? These are the main retrospective questions a burndown plot facilitates visually. Burndown reports are not immediately intuitive, so will require some extra study.
Notice how the hours used, i.e. “burned” according the black line, may exceed the estimated trajectory by being below the red line or have plenty of extra hours if above.
Remember that the hours are assigned to the beginning date and the dashed line represents the estimated trajectory of using up hours until hitting zero at the end date. The filled area stepped line of hours then gets decremented (along the y-axis) with each time entry (along the x-axis).
So interpreting the examples above:
The Overall project is over budget, i.e. exceeds the number of hours estimated since you can see how the final number of hours burned goes below zero, ie the end of the red dashed estimated hours. This Overall project represents the sum of the burndown for all Tasks.
The burndown for the 1. Import Task starts off with 10 hours and only uses up 5.7 hours total (add duration_hrs
from all time entries in the table below the plot), leaving an excess 4.3 hours under budget. In other words, this Task took less time than originally estimated.
The burndown for the 2. Tidy Task starts off with 5 hours, which gets burned through and below by Nov 10. In the end the task is 7 hours over budget.
The burndown for the 3. Transform Task starts off with 5 hours, which gets burned up exactly all in one day Nov 12, so the task is exactly on target with budget.
Please use the following Google Form to submit a Link to your web page with Burndown plots and time entry tables for Overall and individual Tasks, i.e. https://{user}.github.io/time
: