• ForDevelopers
• Sprint

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.

For next sprint

• Improve Daily:
  • Try not to solve problems directly in the daily. Instead, find time and place to solve them.
  • Stop discussions that run on for too long. Sprint monarch should moderate, others should have an option to signal a boring discussion.
  • Keep the "What I did yesterday" part short if it is not relevant for a blocker
  • separate "blockers" from "how much time do I have today and when".
  • When deciding on meeting times, quickly repeat the goal of the meeting.
• New concepts in last sprint:
  • Grab bag of 1-point stories. Could try this again but it should be clearer how it is supposed to be used.

  • Ranked-Choice Voting (with https://www.rankedchoices.com). Had upsides and downsides. The choice of whether to use it again is up to the sprint monarch.

• Reduce pressure at the end of the sprint to finish all stories:
  • dropping stories to focus more on others is good but finishing stories under time pressure just to make the deadline should be avoided.
  • Count Haslums partially for just the parts that were achieved?
  • weekly meetings to finish stories outside of sprint?
• Use meeting room for sprint planning, not the PhD office.

Old "To Improve" Outcomes

To Improve After 2023-Sep Sprint

• 1 week sprint is good for many open stories. Otherwise prefer longer sprints.
• Have more small tasks on the board, use (traffic light) magnet (also outside of the daily).
• Make it easier to find a new point to enter.
• Organize the daily by topic.

To Improve After 2023-Jul 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.

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.