Projects/Geometry Nodes/Sprint12

Sprint 12

  • Start: 2021/03/22
  • End: 2021/03/26
  • Goal: Finish the documentation of the previous sprints (modifiers, everything nodes).


  • Jacques: 3 days
  • Pablo: 1 day
  • Hans: 4 days
  • Simon: 1 day



Sprint Review

For this sprint there was no retrospective. Instead the team did a retrospective for the entire 1st and 2nd cycles of this project.

What went well

  • Working in a team in a single problem with focus, regular feedback sections and shared responsibilities (#1).
  • Very directed building of a feature (#1).
    • Validated the design and worked as foundation for further development (#1).
  • Give the proper time it requires to build the right solutions (#2).
  • Emphasis on re-validation of priorities without overhead/constraints of format (#2).
  • Getting to a better design and focus with the problem well defined ahead of time (#1).
  • Having a cycle to polish the foundation managed to get a lot in Blender (#2).
  • Community involvement, aligning with community, design ahead of patch (#2).
  • Splitting the project in two cycles.
    • More closed/focused and then another with more community involvement. (#1 #2)
  • Focused-single themed sprints (#1)
  • Quality of the deliverables was very high and polished (#2).
  • Cut down the time for meetings that didn’t require everyone (#2).
  • Kickoffs helped the team feel like working together (#1, #2)

What didn't go well

  • Too many rigid targets (#2).
  • Too many things that needed to be designed (#2).
  • Design weeks lacked work ahead of time (#2).
  • Having a bottleneck like design conflicted with pre-established rigid deliverables.
  • Design throughput was a bottleneck (#2).
  • The footprint of working with daily kickoff and other meetings is high (#1).


  • Cutting down the number of targets (#1 vs #2). Separate projects into multiple projects if needed, to help focus.
  • Communicate to the world ahead of the project that the project will happen, where to find updates (e.g., weekly notes) and how to get involved.
  • Dedicate more structured time for design.
  • Make sure the hand-over is planned as part of the project.
    • The project itself can include time for handover.
    • A subsequent project can be proposed only to handle that (e.g., nodes task-force)
    • The project teams should be able to be involved in the module after the project.
    • It helps if it is clear what is expected as part of a hand-over.