Continuous (Pre) Planning in Agile

One of the key meetings in a scrum cycle is the pre-planning meeting. In summary, it’s a long meeting and after that, there are hours of writing subtasks and time estimations. In this meeting, the team members understand the user stories, challenge the PMs, and do estimations. Later, the developers will decide on solutions and break them into subtasks.

Background About the Team

Team Structure

My team is cross-functional. I have frontend and backend developers, as well as more DevOps oriented engineers. It means that developers sometimes have independent tasks that are related only to one or two of them.

Products We Own

We are responsible for three major products and some minor ones. In one sprint, we work on different products. Those products are usually unrelated to each other, so they're called independent tasks.

Team Culture

In the beginning, the team was small, as was the company. We had a startup culture: deliver fast, no planning, no estimations. People hated long, boring meetings because they felt like a waste of time.

The Problem

As it turned out, there were many problems in the way we tried to work. There were common issues that were raised in our retrospectives.

Retrospective

Here’s a list of the main issues we noticed, along with my personal observations:

• During planning, there were long discussions that were only relevant to one engineer and the PM (as a result of different products and the cross-functional team). People were bored and lost concentration.
• Many user stories were not even started because we discovered that the PMs did not clarify them. We discovered that in the middle of the sprint.
• User stories were not done because of a lack of planning.
• We often either overestimated or underestimated the content of the sprints. 
• There was a lack of ownership. Features were not done because dependencies issues were not thought of in advance.

The Solution: Continuous Planning

At one point, we started doing things differently. After several iterations, it became called continuous planning.

The idea was simple. I asked our PM to provide user stories of the next Sprint when current Sprint began. Then, I checked them and assigned them to the relevant developers or pushed back to the PM. The developers started looking at and understanding the user stories. They also added planning using subtasks and time estimations.

We basically had almost two weeks to plan for the next sprint.

How It Works

User Stories Are Ready in Advance

The crucial part here is the timing. When are the user stories ready?

Let’s say the Sprint duration is two weeks and it starts on Wednesday. The idea is simple: On Wednesday, when Sprint 18 starts, then PM should provide all user stories for Sprint 19.

By "provide," I mean:

1. The user stories should be in backlog under Sprint 19 (we use JIRA to create sprints in advance).
2. The user stories should be well defined (Description, DoD, etc.).

First Check

The user stories are assigned to me and I go over them. I verify that they are clear with proper Definition of Done. I identify dependencies between the user stories. Then, I either assign the user story to a developer or reassign it to the PM with a challenge about the content or priority.

Discovery and Planning by Each Engineer

During the current Sprint, each engineer will start planning the assigned user stories for next sprint. He or she will speak directly to the PM for clarifications and will identify dependencies. He or she has full authority to challenge the user story for not being clear. He can reassign it back to me or the PM.

Collaboration

If there is dependency within the team, like FE and BE, then the engineers themselves will talk about it and assign the relevant subtasks in the user stories.

Estimations

The estimations are part of the planning.

Each developer will add his or her own subtasks with time estimation.

Timing Goal: It’s All About “When”

The key element for success in this process is timing. Our goal is for all user stories for the next sprint to be fully provided at the beginning of the current sprint. We also aim to have all user stories planned (subtasks and estimations) one to two days before next sprint starts.

Observations and Conclusion

Our process is still improving. Currently, around 10%-20% of the user stories still come at the last minute, violating the timing goal. We also encounter dependencies that we didn’t find while planning.

Here’s a list of pros and cons that I've already seen:

Pros

Responsibilities and Ownership

One of the outcomes that I didn’t anticipate is that each developer has much more responsibility and ownership on the user stories. The engineer must think of the requirement, then design and find dependencies, aside from only doing the execution.

Onboarding New Team Members

New team members arrived and had a user story assigned to them on their first day in the office. They "jumped into the cold water" and started understanding the features, system, and code almost immediately.

Collaboration

Since each team member is responsible for the entire feature, there was increased collaboration between the team members. There is constant discussion between the team members.

It has also increased the collaboration and communication between developers and PMs.

PM Work

As the PM works harder (see cons), by continuously planning he is forced have better planning ahead.

This process “forced” the PM to have a clear vision of three to four sprints in advance. This clear vision is transparent to everyone, as it is reflected in the JIRA backlog board.

Visibility and Planning Ahead

The clear vision of the PM is reflected in the backlog (JIRA board in our case), making it more transparent. As the board is usually filled with a backlog that is divided by sprints, the visibility of the future plan is much better.

Cons

PM Work

It seems that the PM has more work. User stories should be ready in one to two weeks in advance. The PM needs to work on future sprints (plural) while answering questions about the next sprint and verifying the current sprint status.

Questionable Capacity

When there is a dedicated meeting or day for the preplanning, it’s easier to measure the capacity of the team. It’s harder to understand the real capacity of the team while the developers spend time on planning the next sprint during the current one.

Architectural and Design Decisions

Everyone needs to be much more careful in the architecture and design of the system. As each developer plans his or her part, he or she needs to be more aware of the plans of other developers.

This where the manager or lead should assist to make sure that everyone is aligned and that there’s good communication.

Less Control

The lead or manager has less control. Not everything passes through him or her. If you’re a micromanager, you will need to let go.

We identified points where the manager must be involved.

• Dependencies within the team and/or with other teams
• Architectural or design decisions
• System behavior

Conclusion

We established a well understood, simple to follow, clear process. This process is good for our team. It may also be good for other teams, perhaps with some adjustments.

As described above, if...

1. There are different roles in the team (FE and BE),
2. The team works on different products and projects in the same sprint, and 
3. People feel that the pre-planning meeting is a waste of time

...then perhaps continuous planning is a good approach.