Page Comparison

...

Background

This is the second Sprint we plan on this platform, and the first one () has showed a working capacity of 1.15days/week, so we planned it for an amount of issues of 3d 6h (Estimated Time) considering 3 weeks = 3.55days.

Retrospective

The present retrospective is about the 2nd Sprint we had, starting January 2020, which aim was ”To have a full implementation of REST API while keeping the "gui" up and running, plus some enhancements coming from unplanned issues and tickets (bugs)”.

For this reason the outcome version coming from this Spring was supposed to be named 1.9.2, but both the Sprint issues have not been completed, and other problems (tickets) occurred on version 1.9.1, that has been changed to 1.9.1-pre and it is at the moment under bugfixing.

...

We have also added a new task in the Sprint (OP-178) yet to be merged, so the estimated remaining time has increased and also the Sprint lenght (1 week more, ending today)

NB: the small descending tooth is due to one hour logged directly on Jira, the worklog commited with smart-commint on devs' forks it is not showed on the graph until they are merged (that’s why we consider only closed issues).

The focus factor this time has been 0 (if counting the closed issues, less than 0.025 if we count worked hours) so the average with the previous one is (0 + 0.058) / 2 = 0.029 => 0,575 d/week, means that for the next Sprint we cannot plan more than that amount of work for the team per week (next Sprint of 3 weeks = 1d 6h)

We should then:

• Step1: to finish bugfixing on 1.9.1-pre and release 1.9.1

• Step2: to merge 1.9.1 fixes on ‘default/master/develop’ branches and repeat the Sprint for the 1.9.2-pre

For each new releases, we should branch and create a new branch X.Y.Z so both release and bugfixing can go at their own pace.

...