Proposal: Planning Upcoming Milestone Ahead

Brief Background

In gl-retrospectives/create-stage/source-code#13 (comment 276351714), I mentioned that I think we should be looking at the deliverables that will be working in the upcoming milestone.

I feel that this should be done weeks before the upcoming milestone. Given our async nature, I think this should be done 2 weeks before to give ample time for asynchronous discussion.

Why?

This idea started because of a deliverable assigned to me. Before proceeding, discussion with other counterparts was needed first. Since the milestone was short and there were holidays, the discussion was held ~2 weeks before the milestone ended and slipped. There was an understanding that it'll slip because the development month was short though.

In another previous release, I also got assigned with a deliverable that has vague requirements and needs clarification from the people involved. It took a few days to have a clearer understanding of it for development to start.

Without thinking about the holiday and other factors, I feel that it could've been prevented if the discussion was started before the milestone started.

Requirements

There are issues set for the upcoming milestone 2 weeks before it starts. If there's none, then there's nothing to look at. 😄

Process

If you haven't read the code, you haven't investigated deeply enough

-- Nick Thomas

For a start, I think we can try this out for BE engineers first.

1. On 4th of the development month (this is 14 days before the 17th), BE engineers look at the list of issues that are set for next milestone.
2. While looking at issues, see if there is already a discussed backend solution/plan or none yet.
3. If the discussed backend solution/plan isn't that clear, clarify it.
4. If there's no solution/plan yet, devise one. Doesn't need to be a detailed solution/plan. Feel free to ask other people to pick their brains.
5. If there's a need to collaborate with stable counterpart to devise a solution/plan, add a comment and tag relevant counterparts.
6. Give issue a weight if there's none yet. Or update if the existing weight isn't appropriate anymore. Leave a comment why a certain weight is given.

Benefits

Discussing and devising solution/plan will be done outside the development month and has ample time to be done asynchronously. This gives us time to dedicate the development month for actual development of the issue's solution.

This gives us the opportunity to take a look what issues are planned to be worked on in the next milestone. Even those issues are not necessarily going to be assigned to the person who looked into the issue, I believe that helps us to understand what the team is trying to accomplish.

It also provides a way for the team to collaborate. Since each BE engineer will look into issues, whoever gets assigned to work on a deliverable, will benefit from the discussion/planning done.

I believe this is going to be helpful for stable counterparts (FE, UX, SET and AppSec) that needs to be involved with the deliverables as well. They get involved earlier rather than later.

Thanks to @kerrizor's feedback, another benefit is:

Additionally, I think that it smooths the transition between iterations to have the overlap. It helps avoid the race to the finish I see many engineers doing, and I think actually underlines the "slipping is ok" messaging, as it defuses the stakes, making the continuity of work flow from release to release more obvious (rather than a series of deadlines.)

Risks

May be more work for each of us

We do have planning rotation for weighing deliverables but only 1 BE engineer is assigned to do this. With this proposed process, all BE engineers will be involved.

Also since this will be done while we're working on other deliverables, it adds more work on top of work that needs to be done in the current milestone.

Though, I feel we can look at it in a way that we're just being proactive and doing some stuff in advance so there'll be fewer things to be done when the next milestone comes.

Some issues likely won't end up as a deliverable

Since I'm thinking of doing this 2 weeks before the milestone ends, there is a possibility that the issues we looked into won't be a deliverable depending on our capacity and priority.

It may look like a wasted effort but since we've already done some work into some of the issues, once we get into those issues, work will probably be lighter.

Proposed solution may be considered the solution right off the bat

In this proposed process, we devise a solution/plan before the milestone starts. It could be that at that time, the solution is the best approach but at the point the development starts, things changed.

I believe it's still up to the assignee to know more about the issue before actually implementing the solution. The proposed solution/plan should help and guide the implementer. If it is still deemed the best approach, go for it. If not, come up with a new plan.

Tracking Effectivity

Given the purpose of this proposed process is to avoid slippage of deliverables, I think that's the metric that we can track. If the percentage of slippage decreased, then it means this is effective. If not, it's likely not effective. We can track this for 3 months.

Of course there are other factors that could lead to slippage like unforeseen scenarios, sick, unplanned OOOs, etc. Those factors are uncontrollable but shouldn't happen often. But I think we should take some of them into consideration to have a more accurate number.

I come up with this formula to track the percentage of slippage of a certain milestone taking the actual capacity into consideration (not sure if this is actually known somewhere, if it is please bear with me 😄):

(1 - (total number of deliverables done / (total number of deliverables * actual percentage of team capacity))) * 100

Where:

• actual percentage of team capacity - this is the team capacity at the end of milestone in percentage. Default to 1 but will decrease depending on the capacity of each team member. PTOs known before the milestone shouldn't be considered here as it is already factored when deliverables are assigned. Example: if a team member expected to be available for the entire milestone (20 days) became unavailable for a day, then the percentage will drop to 0.99.

For example, if the total number of deliverables is 10, the actual percentage of team capacity is 0.8, and total number of deliverables done is 8, then the percentage of slippage will be 0%.

Questions

• What do you feel about the possible additional work load of this proposed process?
• Do you think 2 weeks is too much or enough?