MOLGENIS Research Platform - Sprint 2

Mission: by end of this sprint we have ONE user interface to

• Register and login users and limit their permissions (#715,#714)
• List and explore available Investigations (#698)
• Explore and download data as a matrix with rows as targets, features as columns (#652, #719)
• Upload data in a clear Excel form or just as files with a wizard to assist the user (#716, #690)
• Define protocol applications, that is, set observedValues on targets via an auto-generated form based on Protocol (#699,#717)
• In case of computational protocols, run the protocolApplications and monitor progress (#725)

Start: 14 Feb 2011

End: 3 Mar 2011

User stories selected by Matrix team

Joris, Despoina, Joeri, Morris (test user Roan)

No results

Velocity: 45; Standup: Every day at 9.30 (Tue/Thu at LifeLines, 9.00)

User stories selected by Protocol team

Erik, Jessica, Robert, George, Alex, (test users Laurent, Marcel).

No results

Velocity: 45; Standup: Every day at 9.45h

User stories moved to the Sprint Backlog

No results

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.