Arvados

h1. 2014-04-16 Dev tools and data/resource management

h2. Retrospective notes

Timing

* Longer review meeting (always goes into overtime) → extended to 1.5 hours.

* Later review meeting (Pacific Time friendly) → moved.

Kick-off

* Focus on assigning stories

Demos presented by individual developers

* Explicit preparation

* Make screen shots along the way (even during development!) so you have material to present

* Add "screen shots" to before-you-merge checklist?

Backlog visibility

* Update the story progress better! Lots of stuff sticks at "New" when it's actually inprogress or done.

h2. FINISH EARLIER DANGIT

* Tuesday night is the end. In Wednesday sprint review, "almost done" is pronounced "not done".

Branches and stories

* Review comments generally go on stories

* But if you have a big story, you might not want a giant branch/review/merge

* Then you shouldn't have a big story! Recognize that, and split the story.

Take your tasks! Unassigned tasks are everybody's problem, according to redmine's "my tasks" view.

h2. 2015-07-08 Sprint Retrospective (or around that time)

We decided to go from 3-week sprints to 2-week sprints so that we can respond to customer needs more effectively without overly interfering with and disrupting the on-going sprint activities. 

h2. 2016-03-16 Sprint Retrospective 

*Problem:* We discussed about a lot of rework happening during *Review* process, which had been an issue for a long time. We agreed that the stories often time are under-specified and the reviewer identifying gaps during the review process. 

*Solution:* We collective agreed that between the assignee and the reviewer and the product owner, we must ensure the story clears states any *Acceptance criteria* before the assignee starts working on the ticket.

h2. 2016-05-25 Sprint Retrospective

*Problem:* Reviews usually are not happening at a prompt manner and hence the tickets cannot be resolved before the sprint ends. This also had been an issue for a long time. Oftentimes, a story gets implemented but the reviewer is busy with other tasks and gets to review during the end of the sprint.

*Solution:* Tom came up with the idea of having a "schedule" around the reviews. We agreed that each engineer will check if s/he has any pending reviews first thing in the morning and addresses them first. Each engineer thus tries to respond to any pending reviews within 48 hours and reports in the daily standup. 

h2. 2016-06-08 Sprint Retrospective

*Problem:* Backlog grooming. We had been aiming to spend some 10% or so time grooming. However, this had not been the case. We end up spending significant amount of time on a few tickets during the backlog grooming sessions. This is not working because we are not able to groom enough stories with this strategy.

*Solution:* Rather than grooming extensively during the grooming sessions: (1) during the first backlog grooming session of the sprint (first Tuesday after a sprint kick-off), we will assign stories from the top of the *Future sprints* to team members, (2) by the second grooming Tuesday of the sprint, those individuals will groom those tickets by engaging in / initiating any discussions needed to groom and fill in the details on the tickets. By the time we kickoff next sprint, using this approach, we aim to have enough clarity on the tickets to help story point them with more confidence.