Version 9 (modified by 13 years ago) (diff) | ,
---|
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 and then break them down as it becomes clear how to do this.
- 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).
- 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).