EOL Development Processes Kristen Lans Biodiversity Informatics Group

1. EOL Development Processes Kristen Lans Biodiversity Informatics Group Marine Biological Laboratory, Woods Hole, MA klans@eol.org

2. Improve publishing feedback process in content partner registry • Use the source element to create the source link for images • Create a 'Harvest Tonight' button in Content Partner Resource page • Provide an option for users to filter images by species in their chosen hierarchy • Edit the user preferences page to add a "Filter content to this hierarchy" checkbox • Edit the query which looks for images for a page to limit to species in the primary hierarchy • Edit the random images calls to only show images of species or leaf nodes when this option is selected • Consistently apply SPM categories/terminology across different EOL schema uses • Headings Menu in the Add New text tool should reflect SPM categories • Upgrade Prototype JS framework • Enable intelligent, compiled rendering of literature references throughout the website using existing algorithms • Species extinction clock • Add LookAlikes category to the SPM items in the EOL Taxon Resource Transfer Schema documentation

3. How are we doing it? Tools • JIRA: a project management and issue tracking system • Wiki for documentation Processes • Planning every 2 or 3 weeks • Daily ‘stand-up’ meetings • Including Stakeholders

4. Teams • We currently have four development teams here in the BIG, shown in the table below.

5. Each team works in iterative cycles (in a modified "scrum" form of Agile software development), which means at the beginning of each iterative cycle, the teams are assigned enough work to fill up the given period of time for that iteration. • The responsibility of any stakeholders is to identify their own priorities, scope the work, indicate its relevance to a project goal, and identify the desired outcome, such that it is clear to everyone when the task is complete. • The responsibility of team members is to estimate the time required to complete tasks that have been given a high priority, pull as many as possible into a given iteration and then complete the work during the iteration. • Stakeholders agree to not add new items in the middle of an iteration, unless they are urgent, and then must remove other items when doing so. • Direct communication between the development teams and stakeholders is encouraged in order to ensure the stakeholders desires are met, or that if compromises are needed, they are acceptable.

6. Currently the EOL Website Team and the Name Infrastructure/Content group (which plan their work together) operate on two-week iteration cycles, and the LifeDesk team works on three-week iteration cycles. At the end of each cycle, an end of iteration meeting is held individually for each team, where the teams review their accomplishments, discuss how the iteration went, and where work is planned for the next iteration. Iteration meetings are usually held on Fridays unless a scheduling conflict occurs.

7. Planning Meeting • Demo: agile development shows incremental progress • Review: how did it go? Improve process • Plan: What is most important for the next 2-3 weeks? • JIRA Planning Board demo

8. All requested work is placed into a product backlog for each project within Jira (the tracking system which records all work being done within the group), and work is pulled from the backlog and moved into an iteration during the meeting. It is important for the work requested by all of the stakeholders to be prioritized relative to each other and to ensure the work is correctly scoped in the product backlog prior to the iteration meeting so that the team can estimate and plan for the next iteration effectively. Each iteration is assigned a version number, and it is possible to look at the current status of any iteration by looking at the project in Jira and filtering by this version number. The current iteration is the highest version number. For the EOL website, the version number of the released code is visible in the footer of each page. Mid-iteration code releases result in a .dot increment version number release.

9. Day-to-day • Every morning a SHORT meeting to say: -What did I do yesterday? -What am I doing today? -Blockers? • JIRA Task Board demo

10. Since the product backlog can be and often is quite large, with many competing requests from many stakeholders, it is helpful to break the backlog up into Jira "components" (focus areas -- not necessary along EOL Components) and consider working on certain areas during a given iteration or iterations. Since each iteration meeting requires one or more stakeholders to select work tickets and move them to the current iteration, this process invariably involves making difficult choices about what not to work on for that iteration.

11. Feedback and Requirements

12. During development, it is important for stakeholders for a given feature being worked on to continue to be involved and in communication, as there are often tradeoffs or additional questions that occur as development proceeds. Without a line of communication between developer and stakeholder, these questions may go unresolved, either impeding development or leading to incorrect assumptions. These situations often lead to delayed deployment or re-work, increasing the overall project cost.

13. New tickets are ‘Unscheduled’ • Stays there until complete (we have to be able to plan it to do it) • ‘Needs Feedback’ • Story and Acceptance Criteria • Prototype/Review • Release

14. Questions?