The way we develop software has evolved dramatically over the years. Extensive business concepts are a thing of the past. Detailed project plans mapping out every single step from A to Z are no longer desired. Today, it’s all about communicating the idea and the vision behind the software. It’s about inspiring the people involved in the development process and then working toward that vision using agile practices.
In this blog post, we give you exclusive insights into one of our projects and show how you and your team can create a plan that is both robust and flexible in an agile environment. A plan that provides orientation for stakeholders and sets the right direction for the development teams.
Introducing the Project and Its Parameters
Many software systems grow and evolve over time and eventually reach a point where they no longer meet modern requirements. A complete redevelopment often becomes the final step, but the one that makes the most sense. In our case, four existing legacy systems are to be replaced by a single newly-developed system. This means the scope and business goal for your project plans are already largely known. However, all information for the new system has not been fully thought through; extensive laws and regulations need to be considered and implemented within the software.
At a technology level, the system is to be built entirely with current and modern technologies. A small excerpt: The backend will use microservices with asynchronous communication via Kafka. The frontend will be developed using Angular. DevOps techniques will be used for continuous deployment of the microservices in a containerized environment.
Development takes place across an average of four agile teams, each consisting of 7–8 team members and one product owner. The teams are scaled using Nexus with scrum at 2 week sprints. At the start, only some team members know each other. And except for a few domain experts, the majority of the team is unfamiliar with the information they will be implementing.
Agile Project Planning — 3 Crucial Steps
A key parameter is the set of fixed release dates defined by the client. The software must provide a specific feature set by these dates. This means the timeline cannot be changed; only the scope of the software product to be employed is open for discussion. So how do you ensure that the entire team stays focused on the goal and works on the right things? We see the following steps as success factors to prevent the new changes from drifting aimlessly without a clear vision or meaningful task packages.
- The teams and stakeholders must agree on the product to be developed. This means that the aims and vision for the product need to be determined together.
- The scope then needs to be limited. Identify smaller, manageable parts that need to be carried out. We enter the backlog in this step. The backlog items are then prioritized and estimated.
- The resulting backlog becomes the foundation for the release plan. This is where velocity plays a crucial role.
We’ll take a closer look at the individual steps in the next part.
From Vision and Scope to the First Agile Plan
No one enjoys working without a clear goal; a team should always know what they’re working towards. You need to create a product vision that is visible to everyone in the scrum teams. It can be used if questions need clearing up and supports the onboarding of new team members.
To ensure acceptance and a shared understanding from day one, the product vision is not created on an ivory tower. Instead, we place the entire team and the stakeholders at the center of the process. When we say stakeholders, we don’t just mean the client. Stakeholders also include representatives from specialist departments who speak for the product’s future users. And equally important: we involve representatives from the scrum teams such as the product owner, technical architects and domain architects during this phase.
Together, in a series of workshops, this group develops the first shared product vision. A side effect of this process is that the product vision already reflects important cornerstones and parameters of the technical architecture. We remember that new technologies should be used and we’ll need to learn how to use them. Everyone involved has the opportunity to contribute their point of view because ultimately, everyone wants to deliver a working product.
However, at this point, we still haven’t defined the functional scope per release, so let’s head onto the next step. We break down the vision and define a dedicated product vision for each release. All results are documented in a central knowledge system, accessible to every team member.
These product visions now act as guiding stars for development. That’s all well and good, but it’s still not enough.
The Business Process – The Foundation for Alignment
Each release-specific product vision needs further refinement to give teams something tangible to work with. To achieve this, we take a closer look at the business process. With the same team that helped develop the product vision, we run several event storming sessions to analyze the high-level business process. These sessions help us to naturally build a shared understanding of the product. They also help us establish a common language (“ubiquitous language”). And importantly, they provide the basis for the first step and the first boundaries of the microservices.
However, the most important part for agile planning is to think about the technical process, from the start right the way through to the end in this phase. We keep our focus on the happy path, ensuring that the process can be executed. For each business process step, we identify the business topics associated with it. To avoid getting stuck in complexity, we intentionally ignore variations and error cases at this stage. If they are critical to the product’s success, we keep them in a separate area and return to them later.
We repeat the analysis of the business process across several sessions, refining and slicing the business topics into smaller pieces. We increasingly focus on the MVP for each release — the minimum viable product. To do this, we take the product vision for each release as our starting point and identify the business topics that directly contribute to it. Anything that does not directly support that vision is left out and scheduled for later in the development.
A quick word on the heterogeneity of the working group: this diversity is a clear advantage. Even at this stage, it’s crucial for the technical architects to sharpen the understanding of which topics must be included for the MVP, especially when new technologies need to be tested. Testing these technologies too late could negatively impact the overall project success.
At the end of the event storming sessions, we obtain a minimum viable product for each release. Each MVP runs through the entire business process from beginning to end. We know exactly which business topics belong to that release’s MVP per technical process step. By now, these topics have reached the level of epics, giving the scrum teams enough structure to continue planning in an agile manner. All epics are documented transparently in a backlog for scrum teams.
We’ll let you know what happens next in the project in our second blog post “Agile Product Planning – From Backlog to Forecast”.
Looking for professional support with your agile product development project?
Reach out to us — no strings attached — and find out how our Scrum teams can help you move forward.
Discover MID’s Agile Services now!
