User Story
As a team, Reading Web needs to easily see what their sprint goals are, so that they understand why they are doing their committed tasks.
There has been some disagreement about how to track sprint goals. Options discussed:
- Epics in the sprint as the goal (tasks that go through the flow are blocking these epics)
- Placeholder "goal" cards that describe, at a high-level glance, what is to be shipped/resolved this sprint
- Using the Description field in the sprint project page
Epics in the sprint
Pros
- Easy to see how the tasks connect to bigger parent tasks
Cons
- The scope of the epics may be larger than the actual goal of the sprint, thus they don't truly/only represent the actual sprint goal
- Cards in the sprint that the team can't resolve can mess with metrics tools like Phragile
Placeholder goal cards [status quo]
Pros
- Easy to see, at a glance, what the sprint goals are
Cons
- The cards are not real tasks
- The cards don't connect directly to tasks (connecting them is burdensome and unnecessary), so it's easy to make goals that don't have tasks in the sprint related to them
- Cards in the sprint that the team can't resolve can mess with metrics tools like Phragile
- Volunteers may tag the goal cards. For ex: a Hovercards goal card might get tagged with Page-Previews which seems innocuous but in reality messes with the Triage Dashboard filter.
Sprint goal in the project description
Pros
- No excess cards in the sprint (the placeholder cards look like tasks and are distracting)
- Tools like Phragile, which rely on card totals (and points), play nice with this method
- It's intuitive to find the goal in the project description
Cons
- It's awkward to see the goals at a glance when you're not used to looking at anything but the board
- The description doesn't connect directly to tasks, so it's easy to make goals that don't have tasks in the sprint related to them
Acceptance Criteria
- The Reading Web team understands their options
- The RW team commits to a method and creates a process norm