Conference call to discuss possible separation of Features Prioritization (FP) from Testing of enhancement features and bugs. 12/07/2015 at 3pm ET.

Noah – testing, Chair of Migration

Lynda (Governance Board representative) - FP

Kari (notes) - FP

Miloche – testing : already on documentation. Maybe also on FP

Sally – FP, Chair of TAC

Gordon – testing : and FP Chair of UAC

Brad, convener

Julie not present; expressed that she is in favor of the split via email.

Notes taken by Kari Smith, revised by Brad Westbrook

Brad – background:

Considering separating prioritization from quality assurance (testing); constructing a boundary between the 2 sub-teams. Motivated by 1) concern to involve member community, through council reps, more in setting development priorities; and 2) recognition that short, 14-day sprint cycles did not allow much involvement in prioritization. In 2016, there is initial agreement that a features release will be distributed every 4 month and will result from three sprints, each a month long. Maintenance releases to address critical bugs will continue to be distributed as needed.

Today’s Discussion:

What is the process for prioritizing development work. What are the kinds of meetings and frequency of meetings that are needed? How many people at the least are needed?

Scenario posed by Brad / Chris:

De-couple prioritization from development. FP would work independently and in advance of development and would put forward the prioritized development workload; so no need for FP to meet with development team. The Chair of the FP would sit on the development team (scrum meetings).

Developers would then take the priorities and then internally determine how best to address (assignment,sequence, etc.). Testing would be in parallel with development during a sprint, as builds would be issued nightly enabling testers to address their commitments early on in the process. DT would meet at beginning each sprint cycle and go over work done in the previous sprint and then work to be done in the beginning sprint. The meeting would include developers, testers, and product owner(s).

Prioritization team can meet anytime, and as many times as necessary, during a cycle and then hand off the prioritized workload before the next Dev team cycle meeting.

Need to work out Leadership for the two groups. Julie has already been asked her preference.

Comments during Discussion:

Prioritization of enhancements – must be per Sprint (once per month). Another option is to think about what needs to be done for a Release – and then how to schedule that into Sprints. Have the priorities in mind set by the FP group independent of the developer feedback. Then have a negotiation with the developers about what is possible vis-a-vis their capacities. Also, might be best to have releases guided by themes, e.g., imports, exports, digital objects, etc.

What factors does the FP team use for prioritizing development work? Look at what data? Open stories in JIRA? Outcomes of Voting? All? HOW: for first sprint – work from open issues that were voted upon. Then on that basis, bring in related features that haven’t been voted on. For example, focus on Imports/Exports. What’s there in open items and then what’s come in sense. And, that the FP group is to take into account the feedback from the community but not completely driven by it. FP needs to remember it is the community, in a sense. Check EPICS for existing themes.

As we’re looking at the open stories and reported things:

Already been done

No general utility

Actually a bug not a feature

Not a confirmable bug

Consider requesting community to vote on themes (after first two cycles) that the FP put out to them.

Tasks for the FP group:

.. Review the JIRA development catalog and see what is not in an epic.

.. What labels does the FP want to add to the features.

.. Must communicate to the Community who is on the group, how it will work, what it will /will not do.

.. FP must at some point pass off to the developers the prioritized work.

Gordon and Sally will ask TAC and UAC if others want to join the FP. And also Mark Custer of the User Interface team. Not clear on how large of a group should the FP be. Most agree that it can be reasonably small.

Testing Group

Will look like it mostly does now. Cross-council. At beginning of sprints will meet and determine who will test what. Submit pull requests and then have the testing done relatively quickly and the results feed back into the developer’s work per Cycle.

Also, the community will be invited to test release candidates as a release approaches.

Browser not supported