Sprint process overview

Efforts on Hydramata have been refocused toward the Hydra Works community effort. These pages are kept for reference but will no longer be updated.

Regular meetings and attendance needed

Daily Standups: 15 minutes daily, except for sprint planning days.

for team to touch base about what they worked on yesterday and what they will work on today
team members actively working on the project are required to attend and should report daily
POs and PDs are optional to attend but should not report
Lead PO required to attend, but not report
Scrum Master/Tech Lead required to attend
self-reporting is typical
Scrum Master keeps standup on point and on time.
standups often reveal conversations that need to happen later

Demo/Retro/Sprint Planning: Scrum Master leads
- Demo: approximately 1 hr at the end of each sprint cycle.
  - Team members, Scrum Master, Lead PO required: PDs as able. SMEs are also invited but optional.
  - What about Stakeholders? Can we keep those separate?
  - The team demonstrates the work done in the sprint.
  - Attendees ask questions
  - the demo should be planned ahead of time
- Retrospective: approximately 30 mins (could take more or less) at the end of each sprint cycle
- - group discussion about what went well, what didn’t go well.
  - purpose is to identify issues with process, product, etc and come up with a plan to address issues.
- Sprint planning: approximately 1 hour (could take more or less) at the end of each sprint cycle
- - team goes over each story in the sprint, sizes that story for complexity. for each story, team can ask for clarification or bring up potential issues. Stories may need to be broken into smaller chunks or rewritten based on team feedback.
  - after each story has been reviewed, team commits to the amount of work in the sprint or decides if some stories should go into a future sprint.
  - team “tasks” out each story (POs, PDs, SMEs do not need to attend this portion of sprint planning).
  - - tasking out should include all the work needed to get a story done.
    - testing, documentation and merging code are tasks often needed for every story.

Who writes stories?

writing stories is mainly the job of the PO, however others can write stories.
if you do write a story, you can put it in the backlog and alert the PO (perhaps there can be a flag or label)
only the Lead PO can pull stories into the sprint (Jeremy: before a sprint starts all stories in the sprint must have story points?). This will be done in collaboration with the PO team and consultation with the lead PD and the Tech Lead. These decisions are based on the feature priorities set out by the PDs as well as technical needs of the project.
team members can pull stories into the current sprint from backlog ONLY IF everything in current sprint is done or taken and there is capacity. That story should first be tasked out.
if important technical needs arise during a sprint, you should write a story and then let the Tech Lead and Lead PO know so they can re-prioritize stories to make capacity for the work OR decide if it can wait until a future sprint.

How do we decide who does what story?

work is not assigned, but taken voluntarily.
the Scrum Master keeps an eye out that work is being done with attention to priority and tries to resolve any blockers or reasons why specific work isn’t being done.

What makes a story done?

During the lifecycle of a Story, feedback can/should be ongoing.

For a Developer
- Considers a story done when they
  - Believe their code meets the acceptance test criteria
  - Believe the unit and integration tests affirm the acceptance test criteria
- Then the developer
  - Creates a pull request and solicits feedback
  - Marks the issue as Finished
For a Tech Lead
- Considers a story done when they
  - Receive a pull request for a Finished story and
  - Believe the code meets the acceptance test criteria
  - Believe the unit and integration tests affirm the acceptance test criteria
  - Affirm the code tracks to the articulated design vision (this is meant to be a discussion)
- Then the tech lead
  - Merges the pull request into the "develop" branch
  - Deploys a set of Stories marking each story as Delivered
For a Product Owner (and by proxy the QA)
- Considers a story done when they
  - Receive notification that a Story has been Delivered into a QA Environment
  - And they believe the application behavior meets the acceptance test criteria
- Then the Product Owner
  - Accepts the Story

How should I provide feedback?

Everyone (PD's, PO's, Team) can (and should!) give feedback on stories, technical approaches, process, etc. Scrum has many avenues for feedback integrated into the process.

Since we will need clarity and there will be times when decisions must be made, the Lead PO will make final call on feature implementation (in consultation with POs and lead PD) and Tech Lead will make final call on technical approaches.

Mechanisms for feedback:

Commenting directly on the stories
During demo and retrospective
Email the listserv
Contact a PO, or Tech Lead depending on topic

What makes a good story?

Stories are told from the perspective of the user.

Stories are understood by the team and can be broken into discrete tasks.

Stories contain work that are to be done by the team.

Stories are ready to be started.

Stories have acceptance/done criteria

Bug reporting and tracking

Testing will be done on the shared Vanilla Curate Sandbox hosted by Notre Dame.

When you encounter a bug, put an issue in JIRA (use issue type BUG) in the backlog below the purple priority line.

When reporting bugs you should include:

A brief title
Detailed description of the steps you took to produce the bug. It should be obvious to the ticket reviewer, how to reproduce the bug.
Include the expected behavior vs actual behavior.
Build number, found in the footer. Example Build: 2013-12-17 16:12:41
Attach a screenshot
Operating system, browser/version

If a bug seems critical, alert a PO. PO's will confirm the expected behavior or adjust, then make a decision as to whether or not to pull it into the sprint or delay.

If there is a bug that is a result of work done in the current sprint that prohibits the success of the story OR if the bug breaks previously working functionality AND the fix does not require a feature change, these can be added into the current sprint immediately.

Any bug or story that is in the backlog AND above the purple priority line can be pulled into the sprint at any time. Issues below the purple line are there either because there are still under discussion or because we want to wait to work on them.

Issues that come from outside the team will be reported directly in Github. Team members can alert POs when needed so we can track the work in JIRA too.

How do we manage institutional specific work?

It would be great if we could all have access to a generic instance of curate and have local instances customized to our needs (auth, etc)
We will all have institutional specific work - let's try to track most (if not all) of that work outside of our shared process.
Good to communicate that institutional specific work is happening so we can gain capacity