DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Because the DevOps movement has redefined engineering responsibilities, SREs now have to become stewards of observability strategy.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Trending

  • Enforcing Architecture With ArchUnit in Java
  • MCP Servers: The Technical Debt That Is Coming
  • GitHub Copilot's New AI Coding Agent Saves Developers Time – And Requires Their Oversight
  • The Future of Java and AI: Coding in 2025
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Continuous (Pre) Planning in Agile

Continuous (Pre) Planning in Agile

If you're doing Agile sprints and discovering that there are too many unknowns in your planning, perhaps you need to look at a pre-planning phase for your features.

By 
Eyal Golan user avatar
Eyal Golan
·
Sep. 21, 16 · Opinion
Likes (2)
Comment
Save
Tweet
Share
4.8K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Sprint (software development) agile scrum dev

Published at DZone with permission of Eyal Golan, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!