Back to developer page.
Sprint
A Fast Downward sprint is a two weeks period in which we invest most of our time in improving the planner and tackle larger work packages called "stories".
Statistics
We estimate the effort of a story using the fictional Haslum (HSM) score. A Person Day (PD) represents the work one person accomplishes per day.
|
HSM Total |
HSM/PD |
||||||
Sprint |
Work |
Person |
Done |
Pulled |
Done |
Pulled |
Satisfaction |
Queen/King |
2020-June |
|
|
18 |
21 |
|
|
|
|
2021-February |
|
|
4 |
5 |
|
|
|
|
2021-April |
|
|
5 |
11 |
|
|
|
|
2021-June |
|
45 |
9 |
19 |
0.2 |
0.4 |
4 |
|
2022-January |
10 |
45 |
11 |
22 |
0.25 |
0.5 |
4.4 |
Patrick |
2022-March |
5 |
16.5 |
3 |
14 |
0.18 |
0.85 |
4 |
Silvan |
2022-July |
10 |
29.5 |
11 |
19 |
0.37 |
0.64 |
3.7 |
Gabi |
2023-January |
15 |
90.75 |
16 |
52 |
0.17 |
0.57 |
4.3 |
Salomé |
2023-Jan aftermath |
|
|
6 |
|
|
|
|
|
2023-July |
9 |
40 |
14 |
35 |
0.35 |
0.88 |
4 |
Remo |
For next sprint
- Work in pairs more often as a means to distribute knowledge.
- When goals/stories are fuzzy, set a deadline for some subgoal.
- The negative example for this was learning about CMake.
- We could have for example said that we want to have a more concrete plan by day 2.
- Consider defining time boxes for meetings.
- Maybe subdivide meeting into parts and ensure that there is an adequate amount of time to discuss each part.
Old "To Improve" Outcomes
To Improve After 2023-Jan Sprint
- Analyze grid performance
- 3 weeks are long since usually there are things left to do after the sprint, so effectively the sprint is almost a month long.
- Towards the end of the sprint, meet to discuss on which stories we want to focus so we can finish them.
Every story has one person that is responsible for keeping it up to date (board & tracker).
To Improve After 2022-Mar Sprint
- daily meetings: go back to previous model where everyone says what they did and what they can do on that day, but go story by story
- it could be helpful to always pull a story that has an easy entry barrier so that someone who has spare time can directly contribute (e.g., stories which require mainly mechanical work)
To Improve After 2022-Jan Sprint
- Daily Meetings: We will try to report the progress on a per story basis and the plan for the day on an individual basis.
- As reviewer: Provide a time frame for your review (in consultation with the person for whom the review is).
- Feel free to use @everyone to make announcements interesting for everyone.
- If you are searching for new work, just ask in the Discord channels of stories which interest you.
To Improve After 2021-Jun Sprint
We are not happy with our story voting rules. We want to try something new. Next time, one person becomes the product owner. He/She decides the focus of the sprint. The product owner prepares a set of well defined stories (with subtasks). The product owner does not need to know everything, but should consult the developers. It is his/her responsibility to create stories that motivate the sprint participants. At the sprint meeting, the developers will estimate the Haslum scores for each story and select a subset for the sprint.
- We are not happy with the Jira board, but also do not know how to improve it. The board is useful to see on which tasks someone can help, but:
- Some stories have a linear structure. The board is not helpful for those.
In a physical sprint with a physical board, it is easy to find a task and just ask someone in the room what to do for that task, in the virtual sprints with the virtual board, nobody is next to me who can help me start on that task.
- Many stories have to be better defined.