MOLGENIS Research Platform - Sprint 11.12

Mission: TBA

Start: 07 March 2011

End: 25 March 2011

Lessons Learnt from evaluation session of Sprint 3 (11.12) on Mar. 25th

• How to deal with stories/tasks that are added during Sprint? An idea from Jan-Jurjen is to have two lines in the burndown chart: one with the original story points, going down, and one with newly added points, going up. Ideally the two lines would meet at the end.
• Inforsense: considered by Alex and Despoina to have been a waste of time. Just a one-day introduction would have been enough for them. Use-case was too complex. It's strange to have developers evaluate a tool that's meant for researchers.
• Despoina liked the fact that people were helping with eachother's work, for instance with the join queries. Joris, on the other hand, still feels that we are on separate islands working mostly our own user stories. In Scrum, everything is a team effort so we should get rid of this "island mentality".
• Alex's PhD work should be more effectively embedded to scrums.
• Some teams communicated poorly. In George's opinion, there was a lack of commitment. If you will not stick with the plan, don't participate in the Scrum. Of course, not everyone has to participate every Sprint, so you can be exempt from Scrum if you have to for a certain period.
• The teams were too small. George and Robert were practically working alone.
• Should Morris and Joeri be in Scrum teams? Morris is very busy and Joeri has two bosses, making it hard for him to really be a part of a Scrum team here at UMCG.
• Maybe Scrumming over Skype would be a solution? You miss the physical experience of standing in front of the board but at least you can be there very day, which is essential in Scrum.
• Working at home doesn't go well with Agile techniques like Pair-Programming.
• Sprint planning was bad, the Inforsense tasks came "unexpectedly". Plan better in advance.
• It's felt that Morris should take the lead more in deciding (during Sprint planning - not afterwards) which user stories go in and which won't.
• We must keep track of unfinished tasks after the Sprint! Priority ones should go to the next Sprint.
• The stories in Robert's team were not well integrated, lots of loose stuff.
• The Sprint was too short with only 12 effective days. The next Sprint will be 4 weeks instead of 3.
• Roan: mark a checked out task with the owner(s) and the check-out date. Then you can see how long it stays on the board. If it's there too long, it's probably too big or there are blockers.
• Tasks should be small (max. 2 SP), so the burndown graph will go down more evenly.
• You should know beforehand which team member can and will do which task (no surprises on the Scrum board).
• Roan's demo was cut short because we were kicked out of the POB room at 16.30 pm. This has been taken into account for the next booking of the POB room.
• There was too much in-depth discussion during the demo, so we lost time.
• The presentation had become a mess, with slides moved and even deleted.
• Tip: alot time in accordance with team size.
• The first two teams didn't have "team spirit" in their presentations. You could start like: "We're team X and we've done Y story points, achieving stories A, B and C."
• The first two teams didn't demo anything! This is really bad in Scrum. It's Demo Day, so don't show screenshots or code! Show working stuff and a link to the manual. George's screenshots were OK for practical reasons.

User story suggestions from end-of-sprint demo's

Please add or edit; we will put these in trac before sprint on Monday.

• As a user I want to batch upload from file in every screen (instead of copy paste).
• As ontocat search user I want to have my results without duplicates
• As a developer I want to have more cool widgets (E.g. radiobutton widget, or cool Vaadin, jQuery, extJS, JSF, wicket, dojo, whatever widgets)
• As a batch apply user I would like to use the mref input to find and select targets
• As xqtl user I only want to see tabs if there is data in it.
• As a developer I want to be sure that my application is secure (Danny will be test hacker)
• As a apply protocol user I want to have feedback that I applied the protocol succesfully
• As an apply protocol user I want to have the option to start a new protocol application
• As an apply protocol user I want to browse previous protocol applications so that I can edit them
• As an apply protocol user I want to apply defaults per feature or for all features at once.
• As an security user I want to apply permissions on a class and all its subclasses in one go
• As a security user when a form is not editable I expect the edit menu to be hidden from view.
• As a user I want to see what user is logged in.
• As an AnimalDB developer I want to refactor my data model so it complies better to the Pheno model (for instance, subclass ObservationTarget so we can filter on __Type).
• As Protocol designer I want to use 'TargetType?' to specify what types of target can be observed with the protocol