Agile Planning of a Software Project using Deep Planner

Agile methodology is a common project management approach designed to deliver a project sequentially in a dynamic and flexible manner. In the software development world, it is usually represented through the following steps:

1. A big project goal is formulated.
2. High-level planning and analysis are performed for the big goal. The estimate provided at this phase has high uncertainty and should only approximately define the number of resources and timeline required to execute the project.
3. A smaller tactical goal is formulated.
4. Detailed planning is performed for the tactical goal. Comprehensive estimation and decomposition help clarify which resources are required at the moment to cover the immediate short-term needs.
5. The tactical goal is executed. Once it is complete, the revision is made to adopt any new requirements or changes. They are adopted into the big goal and the next tactical goal.
6. The cycle repeats until the big project goal has been implemented.

The main advantages of Agile approach are:

1. Breaking down detailed planning into phases, as opposed to a single planning session before the project begins, saves time in the beginning of the project and creates flexibility later on because requirements are changed pretty frequently during the project execution.
2. Planning and delivery of tactical goals enables project stakeholders to receive continuous feedback from users and adjust the project requirements and estimates on the fly.

High-Level Planning for a Year

Let’s review an example.

Suppose our big project goal is to build a multi-department e-commerce platform for selling consumer goods. The product team has formulated the following requirements for the platform:

1. It should consist of two departments, Food Department and Toys Department
2. Both departments should have their own unique websites
3. The reporting should be consolidated into a single database and have a single user interface

By having only those high-level requirements on the table, a lot of questions pop up in mind. For example, what would be the design of those websites? What are the specifics of the reporting? But at this phase we don’t need to answer those questions because our estimate will be vague and include uncertainty to cover potential risks. We can use assumptions to create the decomposition and estimate resources and high-level schedules.

Let’s start with decomposition. To create a project design, I will be using a tool called Deep Planner that simplifies many steps in the process and makes it partially automated.

For high-level planning of the big goal, we need to plan on a big scale, for example, a year. I will be using yearly deliverables when entering the data into the system.

Let’s enter business features. In our case, a business feature is the name of the big goal, “Multi-Department E-commerce Platform for Selling Consumer Goods.”

As a developer, I decomposed the initial requirements into system components and activities, using a lot of assumptions and high uncertainty. I should enter those building blocks into the system and attach it to the defined business feature.

All right. Let’s finish and publish the decomposition.

Now onto the next step. Once the decomposition is defined in the system we can learn our high-level effort by looking into the Effort Analysis tab; however, it is not too representative because it doesn’t answer the question of how many teams might we need or what approximate delivery date can we count on. To learn this information, we need to build a schedule. Fortunately, it is quite easy to do so with the app.

Let’s create a yearly schedule and enter all deliverables for the basic team setup. Let’s ask the app–and this is quite important–to adjust for the uncertainty factor in our estimates to limit the risk.

All right, all done!

Our schedule was generated automatically, and we have published it. Let’s generate a report.

Here we can see key metrics, such as level of effort and an approximate delivery date, if we execute the plan according to the timeline it suggests. Those values would be planning results for the first step, creating a high-level plan for the big goal.

Planning for a Quarter

Now let’s say we finished planning for the big goal, and we want to start planning for a tactical goal. This is the time when project managers and stakeholders, together with the technical lead, define the first realistic demo everyone can look at and provide feedback on. For example, a project manager, looking at the yearly timeline, can decide that it may be useful to prioritize the Food Department website, and the tech lead can accept this as a priority.

To implement that tactical plan, we need to zoom in onto a quarter-planning and add quarterly deliverables. Let’s switch back to the Decomposition tab and add the business feature “Food department website“ as a quarterly deliverable.

Now let’s define our quarterly system components. In our case, we know that those yearly deliverables fit into a single quarter, so they can just be duplicated from the year with a quarterly planning horizon. At the same time, we update all activities on the Activities tab, which should now map to the quarterly deliverables. The deliverables for later phases can be left unchanged. Here we can see how part of our project becomes defined more precisely while the other part remains to be planned on a high-level.

Now let’s create a quarterly schedule. Let’s add the quarterly deliverables into the schedule.

We need to ensure the timeline matches the timeline we defined on the yearly schedule to ensure execution according to the high-level plan. We can see that this is the case in our schedule timeline. Let’s publish it and review the report.

OK, we can see the key milestones and the scope of work and resources for our first quarter. Quarterly planning is complete.

Low-level Planning for an Iteration

Now let’s consider a more complex scenario when we need to plan for an iteration.

Iterations are shorter time spans, for example, goals set for a period of two weeks, that allow for even more flexibility. It enables doing more frequent releases and iterative testing. 

Let’s switch to the Decomposition tab and look at the system components. 

We know that we need to deliver certain components to achieve our quarterly goals, but they are too big for iteration planning. Before we can use them for building a schedule we need to break them down into smaller parts. Let’s do it. We create two child iterative system components for the quarterly system component X: A and B. We assign different activities to those components accordingly. During this planning phase we can also make our planning more precise and less uncertain. I will add a few business analysis activities that I didn’t add earlier during the high-level planning phase. Now our activities and estimates are more certain.

OK, once this is done, let’s publish the new decomposition and create an Iteration schedule. Let’s add the Iteration deliverables that we defined earlier to the schedule, publish the schedule, and look at the schedule report.

All right, in the report, we can see the precise plans with teams and key milestones for each iteration. We can now easily create activity tickets and start working on those activities for our tactical goal.

Let’s return to our Yearly schedule for a moment.

Let’s update the deliverables data for the schedule. The system actually accounts for the new changes and updates the level of effort according to the decomposition hierarchy. We can see that the new iteration level of effort is now used and our yearly deliverables timeline has slightly updated. Having such a feature in place enables managers to make sure the yearly schedule estimate for the Big Goal is always the most accurate and up to date.

By defining iterative and quarterly deliverables sequentially, we will be moving to a full implementation of the Big Goal step-by-step.

Change Adoption

And the last thing to mention here is change adoption.

This is where Agile shines. Let’s say after the delivery of the Food department website, it became important to make a few adjustments into the Toys department website and add more features into it. It’s not a problem at all. We need to go into the Toys department system components or activities, add the necessary items we want to adjust, and publish the change. Next we update the schedule with new changes and generate a report with a new estimate. We should do it for Yearly, Quarterly, and Iteration plans accordingly to reflect the changes on all schedules. The app will generate new numbers, which are also new key milestones for us according to the new planning feedback. Estimates can increase or decrease, and with that, some business adjustments can be required along the way.

To learn more about Deep Planner and how it can help you in managing your projects, please check out the app website and subscribe to our newsletter to keep up to date on its features. 

For the more context please also check out the video version of this article: