Goal

  • Make development of VIVO minor releases time-based
  • Organize regular sprints to speed up process of VIVO development 

Approach

  • Make development of VIVO minor releases time-based
    • Two minor releases per year, the first one in April, the second one in October
    • If some blocking issue/bug is detected which ruins normal work of VIVO, a patch might be released (it is not time-based, it is “detected blocking issue”-based).  
  • Organize regular sprints to speed up process of VIVO development
    • Topic-based
      • There should be a topic for the sprint which defines wider goal of the sprint
        • Wider goals or objectives could be converted to milestones and have a project board for themselves. An issue can be on multiple project boards to add to sprints and still be on a wider goal project board. 
        • However, some bugs out of the selected topic for a sprint might be fixed. 
        • Moreover, some new features out of the topic might be implemented as well.
        • We also need to be very conscientious of each new feature and how much technical debt it is adding due to existing designs.
    • 4 sprints per year
      • February
      • May,
      • August,
      • November
    • 3 weeks in length
      • Main topic of the sprint and list of issues should be defined before beginning of sprint 
      • The first week - assignment, discussion, deeper analysing issues, organizing of work and finding good patterns, implementation
      • The second week - Implementation
      • The third week - testing, validation, reviewing, code change/correction (as a response to review), merging pull requests
      • Daily meetings - short, what you did yesterday, planning for today, blocking issues
      • Regular developers IG can be organized  - Tuesday
    • Preparation for a sprint
      • We have around 2 months between sprints
        • Noticed there might be a preparation for a minor release between two sprints!!!
        • Vacation or New Year period
      • Selection of the topic for the next sprint is the first task
        • We can’t plan topics for all sprints for the next year, because if one topic is not completed at the end of a sprint, it should be probably a topic for the next sprint
        • However, we can order a list of topics, and simplify the process of selecting the topic for the next sprint (if the previous sprint completed a topic, for the next sprint we are selecting the next one in the list, otherwise the next sprint will have the same topic).
      • Selection of issues already reported at GitHub issues and defining new issues
      • Consolidation of issues
        • Duplication
        • Overlapping
        • Clarification of issue description
      • Detecting dependencies between issues
        • Blocking issue for some other issues’ implementation
      • Making a preliminary plan 
        • Who is planning to participate
        • Assignment (self-assignment) 
        • There is a risk - the last minute cancelation of participation in a sprint, but we have a first week in which we can reschedule a plan 
      • Infrastructure

VIVO release schedule

 


VIVO sprint schedule


Appendix 

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.