2 week sprint process for the cloud content team #31
Conversation
Proposals/2_week_sprints.md
Outdated
|
|
||
| ### Sprint Timeline | ||
|
|
||
| **Thursday (Sprint Start)**: |
There was a problem hiding this comment.
This timeline is a little confusing for me to follow. Could we have everything in chronological order and maybe sections of Before Sprint, Sprint, and After Sprint (for retros/playbacks), and also showing how tasks for the current and upcoming sprint will align? Something like:
Before sprint A starts
Friday before sprint: Decide on the sprint goal and assess team capacity.
Monday before sprint: Prep tasks
Monday - Wednesday before sprint: Story pointing tasks
Sprint A starts
Thursday - Wednesday (two weeks): sprint A tasks
2nd Friday of sprint A: Decide on sprint B goals, etc.
2nd Monday of sprint A: Prep tasks for sprint B
2nd Monday - Wednesday of sprint A: Story pointing tasks for sprint B
Sprint B starts
Thursday - Wednesday (two weeks): sprint B tasks
Whatever day(s) we choose for this: Sprint A playback and retro (these could also happen on the final Wednesday of sprint A)
There was a problem hiding this comment.
I have modified it. Let me know what you think.
There was a problem hiding this comment.
I would even add on here to frame around the sprint ceremonies/roles:
Sprint starts on Thursday, that is when we have planning
In order to have an effective planning call, we need a head of time to know:
- the sprint goal. This should be provided by the "product owner", or in Ansible-verse, the teams' 3itb (PM/Eng Mgr/Tech Lead). This often happens in a "leads" or "3itb" or "priorities" sync earlier in the week.
- if there is work we had to carry over from previous sprint, we should have that identified and tagged for the sprint (some work we may decide to leave in the backlog for now)
- estimated work we can consider for the sprint. This means we need to have completed refinement, which I recommend a team hosts every week, Tuesday is a great day if a sprint starts on Thursday.
- it would also be good to know of any changes to our process or how we communicate, that we may have identified during our retrospective, that we can commit to /reiterate before we start our new sprint!
And then during sprint planning, the flow is:
- align around the sprint goal
- assess team capacity
- pull from the estimated backlog based on previous sprints' velocity (note: we may need to refine last min "new" work, this is acceptable to do in planning)
- if we have time, we can even talk through the issues we have committed to for the sprint, to make sure everyone on the team is aware of each, and then anyone can pull something that interests them, OR decide to pair program
- agree on sprint goal and the work we have committed to, and hit the 'start' button!
This commitments doc may help here: https://docs.google.com/document/d/1FzsaMM6Ryw-n-p8Uog7BjNHJEiOajWg5B2idjlLvDEQ/edit#heading=h.9lxta3fg8qiw
There was a problem hiding this comment.
Yeah @hesmithrh that's super helpful to know not just what happens for each step but what is needed.
Proposals/2_week_sprints.md
Outdated
|
|
||
| To effectively assess team capacity before tasks are added to the scrum board, it is beneficial to plan any planned time off (PTO) in advance and inform the team at least two weeks prior. | ||
|
|
||
| As the sprint progresses, we can calculate the team's velocity, allowing us to adjust the number of story points we select for future sprints accordingly. |
There was a problem hiding this comment.
My sense is that velocity calculations will happen over the course of several sprints as we get used to working in this style and learn what our capacity is.
There was a problem hiding this comment.
+1, velocity = average of completed work from previous 3 sprints
so for a single sprint, sum of the points of the issues we completed (not partial, but fully done). do that for 3 sprints, and take an average.
a helpful report in Jira is the velocity chart, check it out here: https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=20622&view=reporting&chart=velocityChart# (note : for this board there are no reports yet, but you can check out another teams' velocity chart for reference)
Proposals/2_week_sprints.md
Outdated
| - Previous Friday: Decide on the sprint goal and assess team capacity. | ||
|
|
||
| 1. **Monday**: | ||
| - Create a scrum board titled "Cloud Content Scrum <week number>." |
There was a problem hiding this comment.
I recommend we are not so prescriptive "per day", but rather understand the overall sprint flow and how the ceremonies fit within it. Also I think here you are referring to creating a new "sprint", not necessarily a new "board".
Proposals/2_week_sprints.md
Outdated
| @@ -0,0 +1,32 @@ | |||
| ### Sprint Process Documentation | |||
|
|
|||
| The organization follows a two-week sprint cycle, running from Thursday to the second Wednesday of the following week. The first day of the sprint typically involves securing approval on all items added to the sprint, along with their assigned story points. | |||
There was a problem hiding this comment.
suggested reframe: "securing approval on all items added to the sprint, along with their assigned story points." to ---> "as a team, review the backlog and commit to work based on our sprint goal and previous velocity"
Proposals/2_week_sprints.md
Outdated
|
|
||
| #### Sprint A Starts | ||
| - **Thursday to the Following Wednesday (Two Weeks)**: | ||
| - Complete sprint A tasks. All tasks should be closed by the end of Wednesday. Document lessons learned for any remaining open tasks, which will be moved to the next sprint. |
There was a problem hiding this comment.
| - Complete sprint A tasks. All tasks should be closed by the end of Wednesday. Document lessons learned for any remaining open tasks, which will be moved to the next sprint. | |
| - Complete sprint A tasks. All tasks should be closed by the end of Wednesday. Document status, next steps, and lessons learned for any remaining open tasks, which will be moved to the next sprint. |
Proposals/2_week_sprints.md
Outdated
| - **Playback and Retrospective**: | ||
| - Conduct the sprint A playback and retrospective on the final Wednesday of sprint A or at a designated time | ||
|
|
||
| - **Friday following Sprint A**: |
There was a problem hiding this comment.
These things can't happen after sprint A, they have to happen during sprint A. Otherwise they won't be ready for sprint B.
Proposals/2_week_sprints.md
Outdated
|
|
||
| ### Sprint Timeline | ||
|
|
||
| **Thursday (Sprint Start)**: |
There was a problem hiding this comment.
Yeah @hesmithrh that's super helpful to know not just what happens for each step but what is needed.
GomathiselviS
requested review from
a team,
abikouo,
alinabuzachis,
brahmanim,
gravesm,
hakbailey,
hesmithrh and
jillr
and removed request for
hesmithrh
SUMMARY
This documentation aims to provide clarity and structure to our sprint process, ensuring that all team members are aligned and informed.
ISSUE TYPE
COMPONENT NAME
ADDITIONAL INFORMATION