Note: This process was established specifically to meet the needs of the DU project. It's recommended to adjust process according to the unique needs of a team.
Please add items to the backlog using the following criteria:
Specific, actionable – which has a beginning and an end (it doesn't need to have one until added to a sprint).
Good Example: Research and present on how to make a donut.
Bad Example: Eat donuts.
Tasks/stories should have the following information before being accepted into a sprint:
Full description of issue
Dependencies
Assignment
Time estimate
Acceptance Criteria --> What's the "definition of done" for this task?
Task/Stories flow through the follow statuses:
To Do
In Progress --> Move here when you are actively working on it
Review/Feedback/Test (if applicable) --> Move here when complete with a task but needing help from some to review/test it.
On Hold (if applicable) --> Move here if the task is on hold or blocked for any reason
Done --> Move here when the task has fully accomplished its acceptance criteria
Epic – A large development initiative that takes longer than one sprint to complete (usually with an end goal, as opposed to an ongoing effort).
Story – A description of a feature or requirement told from the user POV.
Summary:
High level reason for why this story is needed. As a [type of] user, I want to do [some action] so that I can [get a result/value].
Business context can be explained here also.
Requirements:
Detailed description
Acceptance Criteria:
Example: “A user can upload up to 10 objects”
Design Review:
A designer has approved the pre-PR output
The changes match the provided design spec
Testing Notes:
Anything that may need to be considered or set up to do testing
Resources:
Add designs, wireframes, supporting data docs
What are Planning Sessions for?
Planning sessions are used to identify and scope the proposed work for the upcoming sprint. Typical Agile structure calls for Planning to be done all at once on the first day of the sprint, but nobody loves sitting in a ~4 hour meeting. We will be breaking up planning into two timeslots in order to give everyone time to research and think about what's coming in the next sprint.
Expected outcomes from Planning
A clear understanding of what work will be expected in the next sprint
A clear understanding of the size of the requested work (for appropriate estimations)
What Planning is NOT for:
Catching up/coordinating on the previous week's work
What are Kickoff Sessions for?
Kickoff is the official start to the sprint. In this session, we re-orient ourselves around the why/goals, organize the project tasks, fill in estimates, and trim accordingly. Ideally, by the time the kickoff session happens, most of the planning work is done. This is a quick organizational session to handle last minute issues or needs before we officially start the new sprint.
Expected outcomes from Kickoff
Team is ready to begin work for the new sprint
"Definition of Done" expectations are clear
Estimations in Days (1 day, .5 days, 2 days, .25 days)
What Kickoff is NOT for:
Deeper, more detailed implementation discussion
Deeper dives into the "why" of the project.
Meeting Structure:
[Ongoing] Identify ideas/concepts that can be added to the Backlog
Coordination (1 hour):
Sync between accountable project participants to ask questions and determine the upcoming sprint goal.
Sprint Planning 1 (2 hours):
Review previous sprint
Discuss Upcoming Sprint Goal (if needed)
Backlog Grooming – prioritization and ordering
[To be done Async before Planning Meeting 2]
Prioritize (order) and add points to all work in Backlog.
Define each person's capacity
Planning Meeting 2 (2 hours):
Review current sprint status
Fill any gaps and answer any questions
Assign tasks according to each person's capacity
Start the sprint
In Person (Every Thursday and every other Tuesday)
Async (Every day)
What are standups for?
Standups are a quick sync to determine where people are in their progress on goals for the sprint.
Expected outcomes from Standups
A general idea of how the team as a whole is doing, and what we are working on
Team-members can use this opportunity to ask for help and identify blockers
What Standups are NOT for
Deeper, more detailed discussion on tasks
What is a Demo for?
Demos are a chance for the team to show our work and collaborate. We show off what we worked on during the previous sprint and recognize each other for support and help.
Expected outcomes from the Demo
Celebrate accomplishments
A better understanding of the problems everyone faces
A sense of connection to the team
What Demos are NOT for
Questioning why work was done
Critiquing people's work
What are Retros for?
Retros are an opportunity for us to speak honestly and openly about the project, process, and actions taken over the course of the sprint. We can learn and grow from wins, losses, and team vulnerability.
Note: We will conduct retros via Retrium in order to provide a safe environment for this process.
Expected outcomes from Retrospectives
An outline of lessons learned
A set of action items to adjust and improve
What Retrospectives are NOT for
Punitive action
Blaming/Shaming
Giving up/being passive
What is a Showcase for?
Showcases are a chance for the team to show off their work to company leadership and project stakeholders. This is an external-facing presentation to ensure that leadership has visibility into the work we are doing.
Expected outcomes from the Showcase
Celebrate accomplishments
Expose team to leadership
Communicating challenges and discoveries to external stakeholders
A sense of connection to the organization
What the Showcase is NOT for
Questioning why the work was done
Critiquing people's work
Sprint Ceremony Meeting Map – A breakdown of meeting ceremonies specifically built to work within the Data Upload project team.
Planning Workflow – An overview of the phases of planning and how they flow into each other.
Product Development Process – Each phase of development broken out with associated requirements and risks
Story Development Lifecycle – How do stories move through development into release?
Mapping roles and responsibilities to RACI – Understand what each role is responsible for at each stage of development
Workstream Norming – Who is the accountable for which areas of responsibility?