| Area of Scrum Practice | Answer |
|---|---|
| Assessing effort (story-pointing) | Deem a story an “Epic” if it’s assessed at 40 points. Further review a story if it’s 20 points to determine if smaller stories are appropriate. |
| Backlog review & refinement | We would like to try combining backlog review and storypointing. |
| Defining and adhering to a sprint goal | This could have a beneficial effect on other problem areas. |
| Managing backlogs | Try monthly review/purge of outdated backlog items – review the use of multiple backlogs. And return the idea of using “parking lot”. |
| Meeting management | Set agendas and send them out ahead of time to give the meetings structure. |
| Meeting management | Experiment with smaller groups. |
| Sprint review | Actually talk about things we’ve done and get feedback / demo to stakeholders. |
| Stand-ups or daily scrum | Experiment with a virtual stand/up (Zoom) once a week, and continue with Slack for the other day. |
| Use of sprint metrics such as velocity, burndown, etc. | Try to consciously plan some sprints where we mean to get most or all of the stories done. That would mean refactoring larger stories into smaller ones that could be completed. |
Scrum Summit 2023 - Exercise 1B Summary
Angela Zoss
Day 2 Schedule
| Time Block | Activity |
|---|---|
| 1:00-1:20 | Intro / housekeeping / summary of day 1 |
| 1:20-1:40 | 2A - Experimenting with our Approach |
| 1:40-1:50 | 2B - Scanning our Environment |
| 1:50-2:00 | Full group check-in |
| 2:00-2:10 | Break |
| 2:10-2:40 | 2C - Envisioning New Approaches |
| 2:40-3:00 | 2C - Reporting |
Part 1:
Complete the matrix
Broad agreement that many things need work
Most feel it’s fine
| Area | Comments |
|---|---|
| Writing user stories | Break down larger stories; use tasks as well as stories; inconsistency across POs; not a major problem |
| Handling bugs & problem reports | Lack of points means these can fall off the radar |
More agreement that it needs work
| Area | Comments |
|---|---|
| Use of Jira overall | Jira is hard; separate backlogs make it hard to see full picture |
| Sprint retrospective | Should not be combined with sprint review; feels ceremonial |
| Removing impediments | Having sprint goals would help with prioritization |
| Meeting management | Need agendas for every meeting, sent in advance so people can prepare |
| Handling issues that don’t fit neatly into current projects or sprint priorities | This is hard. |
| Defining and adhering to a product goal | Projects provide a goal, but there can be scope creep, and we may not check that project goals were met |
| Assessing effort (story-pointing) | Break down big stories, combine BR and PP |
Everyone thinks it needs work
| Area | Comments |
|---|---|
| Sprint planning meeting | Would like separate sprint review and sprint planning; multiple projects makes this hard; not conforming to Scrum recommended time or number of stories |
| Managing & reviewing backlogs | Backlogs not pruned enough, possibly lack of ownership over that process; more time on backlog review might improve sprint planning |
| Handling application update & maintenance cycles | Upgrades neglected because they are not features; this is accelerating in a challenging way |
| Facilitating stakeholder collaboration | Not sure about definition of stakeholder or whether this is within the scope of Scrum; need more engagement with external stakeholders |
| Defining the role of product owner | Role varies by product and whether or not the product is in active development; hard that POs have other work |
Topics without any rating agreement
| Area | Comments |
|---|---|
| Defining when something is done | Disagreement about whether this is needed; possible area for PO work |
| Use of sprint metrics such as velocity, burndown, etc. | Breaking down large stories might make burndown more useful; tend to add stories after sprint starts; we don’t derive meaning from burndown |
Mostly needs work, or should start
| Area | Comments |
|---|---|
| Stand-ups or daily scrum | Could help with prioritization; needs to be organized; missing ambient awareness of what others are working on post-COVID; is Slack the right solution? |
| Sprint review | Requires prep time; fewer items in sprint would make this more feasible; too hard with multiple projects; feel ceremonial |
| Defining the role of scrum master | Not well formalized or all-encompassing; rotating is not working well |
Mostly/all should start
| Area | Comments |
|---|---|
| Identifying high-value increments | We try to do this, possibly with certain issues / epics; not clear on value; there may be a role for external stakeholders here |
| Defining and adhering to a sprint goal | Would be useful but is hard with multi-project sprint |
Things mentioned multiple times:
- Having multiple projects gets in the way of many traditional Scrum activities
- Developers need additional help with prioritization
- Backlogs are bloated
- Meetings need agendas
- Need for greater engagement with external stakeholders
- Roles need better definition
Proposed solutions:
- Combine backlog review and planning poker
- Split up sprint review, sprint retrospective, sprint planning
- Break down large stories
Problems without proposed solutions
- Handling issues that don’t fit neatly into current projects or sprint priorities
- Handling application update & maintenance cycles
- How are we determining value?
- Who are our stakeholders?
Part 2:
Identify experiments
Day 2 Schedule
| Time Block | Activity |
|---|---|
| 1:00-1:20 | Intro / housekeeping / summary of day 1 |
| 1:20-1:40 | 2A - Experimenting with our Approach |
| 1:40-1:50 | 2B - Scanning our Environment |
| 1:50-2:00 | Full group check-in |
| 2:00-2:10 | Break |
| 2:10-2:40 | 2C - Envisioning New Approaches |
| 2:40-3:00 | 2C - Reporting |