MOLGENIS Research Platform - Sprint 11.12

Mission: TBA

Start: 07 March 2011

End: 25 March 2011

Lessons Learnt from evaluation session of Sprint 2 on Mar. 3rd

• Sprint planning should be done more thoroughly, really think the stories through. Plan the stories in multiple iterations.
• Tasks should be small and precise so you see progress.
• We should have research stories and tasks (e.g.: investigate error handling).
• Be careful with incoming tasks.
• What to do with new tasks that pop up during the Sprint: add them to the board, including story point estimate, so they become visible.
• Stories that cannot be broken down beforehand: give them number of story points you are willing to spend on them, then start designing (i.e. write the manual) and then break down into tasks as it becomes clear how to do this.
• Supply a template for manuals.
• Have a clear picture of the prerequisites of a task before you start on it.
• Have sessions to get feedback on designs people made.
• Have a history of how tasks moved: maybe write it down on the task post-it.
• Keep Sprint statistics in spreadsheet to learn from.
• Stories were too big.
• 3 weeks may be too short... Suggestion: a month. Or sometimes merge two sprints.
• Demo took to long. At least insert a break. Don't show off products, demo only what's been done. Install a parking lot for discussion items.
• Don't discuss new plans during demo. Do it a day later, so you can think about them. Or do the demos in the morning and brainstorm in the afternoon.
• Morris's role as acceptance guy wasn't properly used. When a task is considered done, ask him to try it, in life or through e-mail. Only when he accepts it, it's allowed to move to 'Done'. He will implement a daily testing slot. Just send him an e-mail and he will test it within 24 hrs (otherwise you may consider the task accepted).
• Bad testing causes old bugs to reappear. Improve testing. Also sometimes SVN merges are done incorrectly, so improvements are lost. Teach everyone to work with SVN properly.
• Work on stable releases.
• Joeri feels he had tasks that were of no importance to the team. Actually, every task is a group effort. We should all adopt this mindset.
• Joeri works on two locations which makes scrumming hard. We have to find practical solutions for his: do sprint planning at Zernike, use Skype for scrum sessions, have the scrum sessions really early so he can attend them every day.
• People who work for other customers (LifeLines, GBIC) feel like that's interfering with our scrum. That shouldn't be the case, the scrums should be aligned.
• Merge the Tuesday and Thursday LifeLines scrums better with ours, so also non-LL people can have a say on those days.

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).