In an Agile project structure, work is not treated homogeneously. Instead, Agile management tries to build an adaptive and transparent process to improve internal communication and traceability. Learn more.
Typically, all the work in traditional project management is homogenous and driven by due dates, which is a problem. While it's acceptable to have an aspirational time frame for a big project, it's not okay when all of its moving parts have specific due dates. It may sound like a strong statement, but this puts teams into failure mode.
With this in mind, it is essential to have a transparent and efficient way of breaking down work. Here comes Agile project management, which doesn't treat all work homogeneously. Instead, it tries to build an adaptive work structure, considering that different factors can influence the system.
You might have seen various ways of breaking down work. In the Agile world, you will meet different terms. Some of the most commonly used terms are, for example, epics, themes, projects, initiatives, campaigns, user stories, deliverables, tasks, so on.
To simplify things, we will focus on the following terminology:
Theme / Initiative – think of this as long-term objectives with a broader focus that will have the most significant impact on your company's performance.
Epic / Project – the epics in Agile are a collection of multiple tasks or user stories. They are usually responsible for producing a major deliverable, which may include various Agile features, for example.
The project, on the other hand, is a very tensile term. If it's size and scope are big, then it might include several project epics. However, people often use "project" and "epic" interchangeably. In general, you can think of them as the building blocks of Agile's initiatives and themes.
Task / User story – this is the smallest piece of work in the chain. It could be anything that the teams are working on (new feature, content piece, design drawing, prototype, legal document, etc.)
No matter how you decide to call the different tasks, make sure to break down all the work from top to bottom and make it visible. This will help you create a transparent work environment.
The focus in Agile is on breaking things down into consumable pieces. These actionable deliverables are continuously shipped to the market without waiting for everything to be completed upfront. This way, you will be able to deliver value to the customers more frequently than usual.
Stick with us, and let's see how you can apply an Agile project structure in practice.
Let's treat these as strategic business objectives in the form of items. They provide business context for decision-making and help you navigate the course of your organization. They also affect the work items you are going to load in the different value streams. Simply said, Agile themes or initiatives sit on top of the work breakdown hierarchy.
To make this clearer, let's take a look at the following example.
Let's assume that you want to penetrate a new market, for example, the project management software market. You can break this down into smaller and actionable projects.
So penetrating the project management software market is your top-level Agile initiative/theme. Now you have to break it down and make it actionable.
The word "epic" comes from literature. There, it represents a long narrative poem, which is usually related to some heroic deeds performed by the main character. But what is an epic in Agile?
Agile epic definition. In Agile project management, epics are larger bodies of work, which can be the building blocks of the upper mentioned initiatives/themes. They should be more specific and measurable so that you can see their contribution to the primary goal.
In the previous paragraphs, we gave an example of penetrating the project management software market as the main initiative. Now, let's break it down to two epics/projects that are:
These Agile epic examples will consist of several tasks, work items, or user stories that need to be completed over a more extended period.
Depending on their size, they can also turn into bigger projects. Regardless of how you choose to name them, the important thing here is to ensure that those epics/projects are related to the main theme/initiative and support the high-level goal of penetrating the project management software market.
10 Years Kanban Experience In 1 Free Book:
When you have a project or an epic in Agile, you need to break it down to small requests that will go relatively fast through your workflow. In other words, this is the lowest level of your work breakdown structure. You may hear terms such as user stories (in software development), deliverables (in marketing), or just tasks on this level.
Let's go back to the PM software example. We agreed that the Agile theme/initiative is penetrating the project management software market, and as an Agile epic example, we will use "Developing New features" and "Enhance current features."
Let's break down the epic/project New Features for PM. What could be the possible tasks that are actionable and small enough? For example, these could be:
The completion of all these small tasks will help you complete the project/epic. On the other hand, completing the initiatives will help get you one step closer to the theme/initiative goal.
This is a rhetorical question. Breaking down work, the Agile way will help you keep track of every project and strategic initiative, and it will bring greater transparency to the work process from top to bottom.
On the one hand, breaking work into the smallest possible size will help your team build a clear structure of tasks and focus on finishing work much faster. On the other hand, the whole structure will provide a guiding direction to the organization.
Let's give a practical example of structuring themes, initiatives, tasks, user stories, and project epics in Agile from our own experience.
In Kanbanize, we have a Master Kanban board, which serves as the top layer of our work structure. There, the management plans, engage in collaborative discussions and visualizes all company strategic initiatives/themes.
Then, we have Team workspaces, where every department builds team Kanban boards (each team has its own board). On top of these boards, team members create a timeline to track the specific Agile epics/projects they are working on. Finally, below the timeline, there is the Kanban board, where we track the flow of the smallest work items/tasks/user stories.
The goal is to bring transparency to the whole work process and to be able to correspond fast to the ever-changing requirements of the market.
So, no matter how you call your tasks (deliverables or user stories), aim to break down work to consumable size, make it easily trackable and visualize dependencies.
Breaking down work, the Agile way has the following benefits:
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.