Skip to main content

The SCRUM Process

Source

NOTE: At the outset of a project, this document and description should be fleshed out by the Project Manager (in coordination with the Product Manager and the team). It should then be shared with the team and posted to the team SharePoint space. It should be updated and maintained (as necessary).

Project Documentation​

Each project should include links to relevant documentation below:

  • SharePoint space for project documentation:
  • BRD/Project Roadmap:
  • Project Weekly Update Space:
  • Product Backlog:
  • Active Sprint Board:
  • Current Release Dashboard:
  • Milestone Schedule Smartsheet:

Development Team​

  • Product Owner (PO)/Product Manager:
  • ScrumMaster (SM)/Project Manager (PM):
  • Business Analyst (BA):
  • Quality Assurance (QA) team:
  • QA Lead:
  • Design (UX) team:
  • Tech Lead:
  • Developers (DEV) team:
  • Accessibility lead:
  • Stakeholders:

Sprint Definition​

Length​

2-week (14 calendar days) sprints

Events​

Daily Scrums (Stand-ups)​

  • Timebox: 15-30 minutes

  • Frequency: daily throughout the sprint

  • Attendees: SM, BA, QA, DEV (UX may attend; PO may choose to attend but not required; stakeholders do not attend Daily Scrum)

  • Objective: The Team uses the Daily Scrum event to ensure that they are on track for attaining the Sprint Goal. Obstacles or roadblocks will be raised to the SM to help resolve. Here are some optional questions to facilitate discussion:

    • What did I do yesterday that helped the Team meet the Sprint Goal?
    • What will I do today to help the Team meet the Sprint Goal?
    • Do I see any impediment or obstacles?

Backlog Refinement (Grooming)​

  • Timebox: 1.5 hours

  • Frequency: held near the middle of the sprint (or as necessary depending on the shape of the product backlog).

  • Attendees: PO, SM, BA, QA, DEV, UX (optional attendees: Team Managers)

  • Objective: The Product Backlog Refinement event is the act of adding detail, estimates, and order to items in the Product Backlog in preparation for the next sprint. Grooming is an opportunity for developers ask questions and for the team to coordinate on a definition of done for each user story. The BA should be prepared to present each user story in the session. The grooming session can include:

    • estimating items (adding story points)
    • adding or refining acceptance criteria
    • splitting items into smaller items or even merging items into larger items
    • removing or demoting items that no longer seem important
    • adding promoting items that arise or become more important

Sprint Planning​

  • Timebox: 2 hours

  • Frequency: held at the start of each sprint

  • Attendees: PO, SM, BA, QA, DEV, UX (optional attendees: Team Managers)

  • Objective: The main objective is to pull in stories from the backlog to create the Sprint and define the sprint goals. Topics include:

    • The PO describes the highest priority tickets to the team.
    • The team decides how much work to pull in based on their velocity and estimated available hours.
    • The team considers any schedule changes that will require adjustments (vacation, days off, etc.)
    • The team identifies possible risks or dependencies that may affect the Sprint scope.
    • Team collaborates and negotiation may occur.
    • The DT collaborates to decide how to approach the work, including design thoughts and sprint backlog items.
    • Team ensures there is agreement of definition of done for PBIs.

Sprint Review​

  • Timebox: 30 minutes

  • Frequency: held on the final day of the sprint

  • Attendees: PO, SM, BA, QA, DEV, UX, key stakeholders (as invited by the PO); (optional attendees: Team Managers)

  • Objective: Some of the information to be covered:

    • Product Owner explains Product Backlog items that have been "Done" and what has not been "Done"
    • Development Team demonstrates the work that it has "Done" and answers any questions
    • Development Team may discuss any problems it ran into, and how those problems were solved
    • Product Owner discusses the Product Backlog as it stands
    • Entire group collaborates on what to do next; beginning preparations for next Sprint Planning event

Sprint Retrospective​

  • Timebox: 30 minutes

  • Frequency: held on the final day of the sprint, immediately following the Sprint Review and prior to next Sprint Planning

  • Attendees: (core team only) PO, SM, BA, QA, DEV, UX

  • Objective: The Development Team, QA Team and Design Team meets with the ScumMaster in order to inspect and adapt the overall process of the sprint.

    • Inspect how the Sprint went with regards to people, relationships, process and tools
    • Identify and order the major items that went well and potential improvements
    • Create a plan for improvements in the way the Scrum Team does its work
    • Select three items to improve for the next Sprint.
    • The Scrum Team plans ways to increase product quality by adapting the definition of "Done" as appropriate

Additional Meetings​

Discovery Session​

  • Timebox: 30 minutes to 1 hour
  • Frequency: as needed
  • Attendees: PO, SM, BA, DEV, UX (QA may attend depending on the scope of the session)
  • Objective: To brainstorm solutions for implementation. The goal of this meeting is to answer open questions that will allow all teams to move into scoping the work.

Weekly Team Meeting​

  • Timebox: 30 minutes to 1 hour
  • Frequency: weekly
  • Attendees: PO, SM, BA (as necessary), QA lead, Tech lead (Team Managers to attend only when specifically invited by PO/SM)
  • Objective: To discuss weekly status for the project. Provide a summary of active work, project risks and concerns.

Weekly Stakeholder Meeting​

  • Timebox: 30 minutes to 1 hour
  • Frequency: as needed
  • Attendees: PO (PO may pull in BA or other team members -- as necessary)
  • Objective: To update stakeholders on progress. This meeting may also be used to discuss specific features or requirements gathering.

Definition of Done​

The acceptance criteria and user stories documented in the ticket have been certified as accepted and passed by QA and UX and accessibility requirements meet the specs defined in the sprint.