One of the key meetings in a scrum cycle is the Pre-Planning. As each team adapts the process differently, it probably has a bit different way of doing this meeting.
However, there are some elements, which are usually common:
- Understand the user story
- Challenge the PO
- Estimations – Story points / t-shirt size
- Design and plan, which include
- oEngineers thinking and planning how to work on the user story
- oEngineers add subtasks to the user story. The subtasks holds information to the detailed planning, and actual time estimations
More Common Elements
There are two more common elements that I experienced myself and also learned from friends and colleagues:
- Pre-planning phase take a-lot of time. The meetings itself is long and then many hours of designing and putting everything as subtasks
- The pre-planning meeting is very emotional:
- Engineers are frustrated because the user stories are not well defined
- PO will sometimes feel “attacked” (“everyone is against me”)
- People get bored
- Talking for 40 minutes about a user story, which is totally not related to them
Let me be clear, I am aware that this is not the case everywhere and for everyone.
But in general, I think it does describe the situation.
The Structure of My Team and the Old Process
As we all know, each team is built differently.
The fun thing with agile, and Scrum specifically, is that we can (should) adjust the process to suit the users.
So this was my starting point:
- “Startup” culture. I.e. deliver quickly, fast response, hate (long) meetings
- Some Kanban/Scrum mixture way of work
- oNo estimations
- oNo breakdown to subtasks
- oHardly no planning / design meetings
- Work on several products/projects in parallel
- oAll managed by one PM
- Cross-functional team (UI, backend, and partially DevOps)
We introduced Scrum to the team. When we started, the team was small. And, as described above, it consisted of Frontend and Backend engineers. We wanted not to burden the team, so we had only one planning meeting. We didn’t have the pre-planning. I thought that we could work with PMs in the planning, do rough estimations and add subtasks later. All in one day/meeting.
As it turned out, we had problems.
In our retrospective meetings, there were issues that kept coming back
- Many user stories were not even started because we discovered that PMs did not clarify them. We discovered that in the middle of the sprint.
- User stories were not done because lack of planning
- Overestimated / underestimated sprints content
- Lack of ownership. Features were not done because dependencies issues were not thought in advance.
- During planning, there were long discussions that were relevant to one engineer and the PM (as result of different products and cross-functional team)
Solution – Continuous Planning
At some point I started doing things differently. After several iterations, it became the continuous planning. The idea was simple. I asked our PM to provide user stories of next Sprint when current Sprint starts.
I checked those user stories, verified they have enough information and assigned them to the different developers. Then I asked the developers to start looking at those user stories. I told them to recheck if they are clear, identify dependencies and approach the PM for clarifications. Then the developers added the subtasks with time estimations.
So basically we had almost two weeks to plan for the next sprint.
It took several iterations to improve the whole process and to the get to the point that it “flows”. A few months, to be more precise.
Let me try to describe in more details…
How It Works
User Stories are ready in advance
The crucial part here, is the timing, when are they ready?
Maybe saying this is obvious, (ready in advance) but the idea will be clearer later.
Let’s say the Sprint duration is 2 weeks and it starts on Wednesday.
The idea is simple: On Wednesday, when Sprint 18 starts, then PM should already provide all user stories for Sprint 19.
By provide I mean have them:
1. In backlog, under Sprint 19 (we use JIRA, so we create sprints in advance)
2. Well defined (Description, DoD, etc.)
The user stories that are ready for next sprint are assigned to me (as the developers manager).
I go over them and verify that they are clear. I don’t deep dive too much, but just check that they are have starting point.
I also try to identify dependencies (mostly with other teams), so I can mark different user stories and talk to other teams.
Negotiating with the PM
User stories, which I am not satisfied, will be reassigned to the PM or discussed on our daily 1:1.
I will sometimes challenge the priorities based on focus of the business.
At this point I might tell the PM that he asks for too much in the sprint, and we need to remove content.
Assign to Relevant Developers
Any user story that “passes” will be assigned to the relevant engineer.
Discovery and Planning
From now on, each engineer, during current Sprint, will start planning the assigned user stories for next sprint.
He will talk directly to the PM and identify dependencies.
He has full authority to challenge the user story for not being clear. He can reassign it back to me or the PM.
If there is dependency within the team, like FE and BE, then the engineers themselves will talk about and assign the relevant subtasks in the user stories.
The estimations are part of the planning.
Each developer will add his own subtasks with time estimation.
All of the above is clear and nothing new.
The only thing, which is different, is when all of this is happening.
If you remember, the user stories for next sprint are provided in the beginning of current sprint.
Everything I described above is happening during current sprint.
Our goal is that all user stories will be fully provided in the beginning of current sprint.
We also aim to have all user stories planned (subtasks + estimations) 1-2 days before next sprint starts.
It took many iterations to improve this process, and we are still not always perfect, but we reached to the point that:
1. Around 10%-20% of the user stories still come in the last minute (a day before the sprint starts)
a. We almost always have user stories that come a day before the sprint starts
2. Dependencies bumps during the Sprint, which were missed in the planning
3. Underestimation of time
If you think about it, nothing big has changed:
We took the pre-planning step, which was a one time in the Sprint, and spread it across the entire Sprint.
However, I did notice some impact:
Responsibilities and Ownership
To be honest, I didn’t even think about this when we started working like that.
But one of the outcomes is that each developer has much more responsibility on the user stories, as well as ownership.
The engineer must think of the requirement, then design and dependencies, besides just the execution.
On boarding new team members
Another advantage, which I have didn’t think of beforehand.
New team members arrived and had a user story assigned to them on their first day in the office.
So “they jumped to the cold water”, and started understanding the feature, system and code almost immediately.
This was mentioned as “things to preserve” in the retrospective. By all of the new members.
As each team member is responsible of the entire feature, it increased the collaboration between team members. There is constant discussion between the team members. Each time different members talk with others, as responsibilities and features change.
And, as we work with another team, remotely, the collaboration with them has improved as well. And as the responsibility is directly on the engineer, we are starting to see better communication between the two teams.
As the PM works harder (see disadvantages), the continuously planning forces him to have better planning ahead.
Another aspect is the developers / PM communication. Each developer is responsible to approach the PM and check if everything is clear. The engineer can push back user stories as well, which forces the PM to constantly improve on the user stories definitions.
Visibility and Planning Ahead
As the board is usually filled with backlog, which is divided to sprints the visibility of future plan is much better.
Anyone can check the board and understand the sprints (plural) planning. We can check the board and see the iterations and how the product incrementally grows.
As any tool / process, the continuously planning has its challenges as well.
I prefer to call this section challenges and not disadvantages, because the issues under this section just make us think harder. I don’t think having them means it’s a disadvantage.
It seems that the PM has more work.
User stories should be ready in 1-2 weeks in advance.
Team members constantly talk and ask questions.
The PM needs to work on future sprints (plural) while answering questions about next Sprint and verifying current sprint status.
When there is a dedicated meeting / dedicated day for the preplanning, it’s easier to measure the capacity. We can say that developers have 9 days instead of 10 (2 weeks sprint) because of the meeting and planning.
But when constantly working on planning, it’s easy to forget this time in beginning of the sprint, which causes the engineers to take more than the capacity they can.
Architectural and design decisions.
As each developer plan his user story, sometimes there should be architectural or design decisions.
Sometimes it affects the entire system, or other team.
So this part is more delicate, and everyone needs to be extra careful and understand the implications of the decisions.
As the control of features is spread among all engineers, and there isn’t a dedicated preplanning meeting, we need to be more strict on how we decide behavior/structure of the system.
This is the manager’s challenge.
Not everything passes through the manager. To be more precise, almost everything does not pass through him.
So if you are a technical lead or “control” manager, you have a nice challenge here.
You need to trust the engineers and let go.
I found out that checking constantly the pull requests and identifying future problems helps me to keep track.
Another thing we established, is that we identified points were the manager must be involved.
Example: any behavioral / design / architecture decision must be informed to me. Then either I open it to further discussion, challenge it and ask questions or I can just ask to inform the people / teams who are related to this feature.
I don’t think that we invented any wheel.
But we established a well understood, simple to follow, clear process.
This process is good for our team. It may be good for other teams, perhaps with some adjustment.
As described above, if:
1. You have different roles in the team (frontend, backend)
2. The team works on different products / projects in the same sprint
3. People feel that the preplanning meeting is a waste of time
Perhaps you should try the continuously planning process.