2016 Draft updated prioritization & testing process and groups

Owned by Sally Vermaaten (Unlicensed)
Last updated: Nov 20, 2019 by Lydia Tang (Unlicensed)

Max = orange

CFitz = Pinkish? Puce?

Sally = Green

 Related call notes: 

Implementation notes

  • Jan 2016 - wrap up of 1.5 release

  • tbd - early Jan setup meeting of Prioritization Team (weekly check-ins?)

  • late Jan - process in place and schedules and meeting invitations in place for 2016 releases

  • late Jan - first Prioritization working meeting (grooming)

  • Jan 29 - backlog prioritization finished - 1mo worth of stories

  • sometime in Jan - Testing team meets

  • Feb 2016 - implement new development process

  • Feb 1 - Sprint planning meeting

  • Feb 19 - end of development and concurrent testing

  • Feb 22 - 26 QA testing

  • Week of Feb 22 - second Prioritization working meeting (grooming)

  • Feb 26 - COB ETD end of sprint

Draft Schedule

One release per every four months, three per year

Three sprints per each release, each a month long in duration

Development and concurrent testing occurs during the first three weeks of each sprint; concurrent testing is supported by nightly builds

Q/A testing for the sprint occurs during the fourth week of each sprint

Community testing of a release candidate occurs for three weeks prior to each scheduled release

Maintenance releases necessary to address critical bugs may occur independent of this schedule.  

Draft Process / Cycle

Note - this is a general outline. Further changes and refinements may be made over time as groups are get underway with new cycle and ideas as improvement are raised.

1.Submission

Who: Users

Process step description: Submit a feature request or report a bug in the ArchivesSpace Support JIRA

When: rolling basis

2. Initial evaluation of tickets.

Who: ArchivesSpace Program Team (Brad, Christine, Chris & Brian)

Process step description: reviews stories in Support JIRA, request additional information if needed and/or respond to submitter if they think an issue / function is already part of the application; whether it’s a bug that’s already been reported; whether it’s functionality that’s institution-specific. 

It would be good for some group to consider improvements to steps 1 - 3 to in particular bug tracking and reporting as we could probably make some improvements. Currently support requests also come via a number of channels and this causes problem for everyone involved in the process. Need to encourage users to log tickets in support JIRA.

Yes, I agree with the bug reporting. It's compounded by the fact the support JIRA doesn't allow users to follow tickets and that people have to add an email. IMO, the support JIRA hasn't really worked out. Would it be best to just encourage people to record bugs in either 1) Github issues or 2) the mailing list.  We add those in JIRA ( since I use completed JIRA tickets to generate the change log )? I think this would eliminate one channel ( the JIRA support ). Users adding their own tickets to the general AR JIRA project often means they just get lost...

Chris - your suggestions sound like good ones that should be discussed / examined further after the new development process is underway. It would be great to have a group (Program Team? one the Documentation sub-teams?) look at the current submission process think through the pros & cons of moving to the 2 alternates you suggest - as well as thinking through any set-up / transition work involved in changing how this is done.  

When: rolling basis

3. Move accepted tickets from Support to Dev JIRA.

Who: ArchivesSpace Program Team (Brad, Christine, Chris & Brian) 

Process step description: moves sufficiently detailed feature (and non-duplicative) requests and bugs into Development JIRA and categorize with a label, e.g. Epic e.g. 'EAD export'.

When: rolling basis

4. Prioritization / Grooming meeting.

Who: Development Prioritization team

Process step description:  meets and reviews and prioritizes all stories related to a particular Epic / label. See charge of prioritization group (below) for additional info. After prioritization meeting, group sure to share information with both documentation groups - TAC and UAC so that updates can be done during the release cycle.

When: Before start of each monthly sprint and/or once before start of a 4-month release cycle

5. Sprint Planning meeting.

        Here's a draft overview of the meeting I made

Who: Chris Fitzpatrick, Brian Hoffman, Julie Patton Prioritization Group liaison (co-Product Owner?), Brad Westbrook - Product Owner, Testing Lead (and/or individual testers), other contributors, (heads of documentation teams may be interested in joining?)

Process step description: meet to look at prioritized set of stories and assess what is possible within sprint & assign stories. Sprint Planning meeting as handoff - devs would point stories, etc. This will also be an open call for the community to listen in on if interested. Testing team lead to identify testers at beginning of each sprint (before, during or after sprint planning meeting?). 

When: Beginning of sprint cycle

6. Development & testing per sprint.

Who: Project Team

Process step description: Project team to work on code and documentation and testers to test functionality as stories are delivered.

Testers added as watchers to tickets so will be automatically notified when a feature is ready to be tested.

When: weeks 1 - 3 of each sprint

7. Q/A testing

Who: Program team ( + others?)

Process step description:  Test deliverables of the sprint during and indicate which stories are accepted for the scheduled release and which are rejected.  Rejected stories may be resolved during the last week of the sprint, deferred to the next sprint, or placed into the backlog for a future release

When: last (4th) week of the sprint

8.  Release

Who: Release Manager, Community Support Manager 

Process step description: The designated Release Manager prepares a Release Candidate three-weeks in advance of the release schedule.

The ASpace Community Support Manager notifies the community of the presence of the release candidate, indicates new features and bug fixes in the release, and invites the community to test those additions as well as other areas of the application

Problems reported are cycled back to the Q/A team for resolution.  Problems may be resolved prior to the release and included in it, or removed from the release and targeted for a later release.  

The designated Release Manager prepares the release, after the community testing period is over and all resolutions made.  

The Community Support Manager announces the distribution of the release, indicating the new features and bug fixes that made it into the release, as well as those that ultimately "fell out".

When: three-weeks in advance of the release schedule - release date


Groups involved:

Development Prioritization

Task:  On the basis of feature requests and bug reports filed in the development catalog, this team prioritizes development work for each schedule features release (1 per every four months) in advance of the first sprint for each features release.  

Leader: Julie Patton

Members: Chris Prom, Daniel Weddington, Kari Smith, Jason Loeffler, Brad Westbrook (Program liaison), Gordon Daines (UAC liaison), Sally Vermaaten (TAC liaison)

Responsibilities:

    • Select prioritized features and bugs for releases and sprints within releases

    • Continual grooming of icebox and backlog (reviewing, verifying, de-duping)

    • Provide clarification / specification - secure from original reporters or provide details [note that going forward a decreasing number of stories should require additional specification as it may possible to request clarification at the stage of original submission and evaluation]

Leader Responsibilities:

    • Schedule and facilitate meetings of Prioritization Group

    • Represent Prioritization Group in Sprint Planning meetings as scheduled by Scrummaster (Chris)

    • Report targets for each release to Scrummaster prior to each Sprint Planning meeting

    • Report to Community Support Manager prior to each Sprint Planning meeting

Prioritization criteria (starting point - to be refined by group):

Meetings: Monthly (1st month -target features and bugs for release and suggest first sprint; 2nd month - suggest targets for second sprint and groom icebox; 3rd month - suggest targets for third sprint and groom icebox; 4th - start preparation for next sprint)

 

I changed this from "Agile Team" to "Project team" just because "Agile" feels a bit loaded. Project might be too generic?

Project team (code, testing, and documentation contributors):

Task:  Implement features and bug fixes and documentation additions according to prioritization determined by Prioritization team.  Will organize prioritized work into three consecutive month-long sprints.  

Leader/ Scrummaster: Chris Fitzpatrick

Members: Chris Fitzpatrick, Brian Hoffman, (Julie Patton Prioritization Group liaison (co-Product Owner?) , Brad Westbrook - Product Owner, Testing Lead (and/or individual testers), other contributors, (heads of documentation teams may be interested in joining?)

Responsibilities:

    • for code contributions, unit tests should be included

    • [Brad to write up notes on overall testing strategy]

      Meetings: Sprint planning meetings, 30min standups 3 times / week (M, W, F)


Testing:

Task:  Testing features and bug fixes, during the first three weeks of a sprint.  

Leader: Miloche Kottman

Members: Ed Busch, Noah Huffman, Scott Hanrath, Max Eckard, Robert Lay

Meetings: Scrum meetings, (additional meetings??)

As a new TAC member who just completed my first testing assignment, I think it would be useful to come up with guidelines on exactly what is expected here, where the outcome should be reported, etc. Maybe this is unique to a particular functionality and gets worked out during the Sprint Planning Meeting?


Quality assurance:

Task:  Testing features and reviewing prepared documentation during the last week of a sprint to ensure all work necessary for a sprint has been completed or deferred to the following sprint.  

Leader:  Brad W.

Members:  Members of the program team (developers, program manager, community manager)

Meetings: