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

04/16/2014 (Sprint start date 03/27/2014)

100%

119 issues   (119 closed — 0 open)

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

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.

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.

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.

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.

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.

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.

Time tracking
Estimated time 160.80 hours
Issues by
Bug

12/12

Feature

9/9

Task

90/90

Story

8/8

Related issues
# Subject Story Points
Bug #2596 Workbench mangles script_parameters when starting a pipeline_instance 1.0
Story #2461 Specify design for Crunch v2 1.0
Story #1968 Monitor disk usage (per user and per site; split by transient/persistent; optionally weighted by #users who want persistent). 2.0
Story #2282 Recurring: write blog post about latest release. 1.0
Story #2451 Developer documentation for Workbench 1.0
Feature #2376 Workbench should display collection tags everywhere it shows collection UUIDs 3.0
Bug #2484 Workbench error when combining existing collections to make a new collection (encountered by Jonathan 2014-03-26) 0.5
Story #2450 Metadata server prototype demonstrates permissions and results reported to the teamĀ  5.0
Bug #2488 Update http://doc.arvados.org/api/schema/Job.html re. nondeterministic and repository attributes 1.0
Feature #2582 shell nodes should have 80/443 open by default 1.0
Bug #2388 Reload on login screen failed 1.0
Bug #2449 New Keep server can write 5.0
Feature #2217 Puppetize script that records VM logins 1.0
Story #1776 User receives automatic email notification when account gets activated 1.0
Feature #2375 Add a row to the Logs table whenever a row in any other [interesting] table is created or changed 1.0
Feature #2228 In create and update, assign/check _kind attributes by inspecting corresponding _uuid. 1.0
Bug #2246 Race condition in crunch-job: multiple jobs use the same /tmp/crunch-job/ on head node to check out git trees and make archives. Fix as simple as using git archive --remote? 1.0
Bug #2547 keep0 and keep1.qr1hi each report 2x most blocks. 0.5
Feature #2487 Finish/merge last sprint's docker work. 1.0
Story #2107 Recurring: ensure docs/tutorials are up-to-date with latest release. 1.0
Bug #2338 Pipeline instance reloads interfere with user's tab selection 1.0
Bug #2243 Pipeline instance page H2 should be the instance's name, not the template's name. 1.0
Feature #2272 Admin can run setup-new-user.rb equivalent with a nice form from workbench 1.0
Bug #2508 Sasha gets "fiddlesticks" error when logging in to qr1hi. 1.0
Feature #2509 doc: make rake linkchecker task and describe in readme 0.5
Bug #2209 arvados.api('v1').collections().list(limit=X).execute() returns ~half X results 1.0
Bug #2447 Workbench search is broken - it always returns everything 1.0
Feature #2498 Support finer grained administrator permissions like read-only, only certain users. 1.0
Story #2068 Administrator can quickly reset a test user account to the "new, inactive, not invited" state with no repository/VM access, and log in to Workbench as that user, in order to efficiently test new user UI/API behavior and activation scripts. 1.0
38.5