Evaluating the results of shifting next sprint planning

Discussions - Public
,
1

[Ticket to log time]

Hi @team (however this thread is mostly relevant only to Bebop, I think this should be company wide discussion),

If you want to learn more details, you should read the following forum discussion, description, comment and attached PRs of BB-8256. The changes have been announced in following forum thread.

At the end of the last year, we’ve been discussing how we could improve the sprint planning. One the issues that was identified, is that it’s hard to estimate whether the next sprint contains too much or too little work relative to the capacity of the cell. The estimation session would open on Friday W2, and close on Monday W3 morning, on the same day the sprint would end. This gave us only 24 hours to identify whether anyone was over or under commited, and attempt to fix it before the start of the next sprint. Due to the timezone difference, the 24 hour window was even smaller.

This discussion inspired changes in the existing sprint process. A summary of the changes that have been done are:

  • The deadline for creating the tickets for the next sprint has been changed from EOD Thursday of the 2nd Week, to EOD Wednessday of the 2nd Week.
  • The asynchronous estimation sessions would open on EOD Wednessday of the 2nd Week (right after the deadline for creating the tickets), and would close on EOD Thursday of the 2nd Week.

The intent of these changes was to give us more time between when the tickets can be assigned estimates and the start of the next sprint to try to spread the work across all members so that no one is over or under committed. The extra time could be used for necessary communication between the affected members, reassigning tickets from over committed members to under committed, and looking through the backlog to fill in the left over capacity.

At least 3 months have passed since the change has been made. In this thread I want to collect feedback from the @bebop members on whether this change has been positive, negative or negligible. Comments and suggestions are encouraged.

Please answer the poll, and if you have any positive, negative or neutral feedback, please share them in the comments of this thread. Additionally, if you have any suggestions on which stats we can collect to evaluate the change, please let me know.

How do you feel about the change?
  • Postive (like the change and want to keep)
  • Neutral (didn’t notice the change)
  • Negative (would want to revert)
  • Other (please explain in the comments, if possible)
0 voters
4 Likes
2

@bebop Kind reminder to vote on the poll, and leave a comment if you have any feedback or suggestions. Until now, only 4 people have voted, which is less than a third of the cell size.

3

Thank you for creating this thread and poll, @maxim.

I personally feel like we improved in this:

One the issues that was identified, is that it’s hard to estimate whether the next sprint contains too much or too little work relative to the capacity of the cell.

I became curious how many tickets we created on Monday W3 before and after this change, so I wrote this simple (any maybe ugly…) script and got the following results:

Before change: 448 issues created before Monday W3, 140 issues created on Monday W3, which is 23.809523809523807% of all issues.
After change: 482 issues created before Monday W3, 64 issues created on Monday W3, which is 11.72161172161172% of all issues.

Perhaps this doesn’t prove anything, given how many parameters affect when we create tickets, but if this calculation is correct, I’m anyway glad we started creating twice less tickets last moment. :slightly_smiling_face:

6 Likes